From owner-freebsd-arch@FreeBSD.ORG Wed Sep 29 20:40:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FD7416A4CE; Wed, 29 Sep 2004 20:40:58 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E33D343D45; Wed, 29 Sep 2004 20:40:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B7A877A446; Wed, 29 Sep 2004 13:40:57 -0700 (PDT) Message-ID: <415B1DD9.2050409@elischer.org> Date: Wed, 29 Sep 2004 13:40:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <1096133353.53798.17613.camel@palm.tree.com> <200409281056.00870.jhb@FreeBSD.org> <1096468734.3733.1177.camel@palm.tree.com> <200409291055.48387.jhb@FreeBSD.org> In-Reply-To: <200409291055.48387.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Stephan Uphoff cc: David Xu cc: freebsd-arch@FreeBSD.org Subject: Re: sched_userret priority adjustment patch for sched_4bsd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 20:40:58 -0000 John Baldwin wrote: >On Wednesday 29 September 2004 10:38 am, Stephan Uphoff wrote: > > >>On Tue, 2004-09-28 at 10:56, John Baldwin wrote: >> >> >>>If A has a priority boost from tsleep() this is intentional, however. >>>The priroity boosts from tsleep() are _supposed_ to do this so as to >>>favor interactive tasks. Note that if you add the code to always raise >>>td_priority while in the kernel as below you may end up defeating this >>>well-known feature of the 4BSD scheduler. >>> >>> >>OK - you and Julian convinced me that this is a feature that I should >>have known about. Without test cases or interactivity benchmarks >>discussions if this is still a desirable feature are probably useless. >>I will revisit the this once test cases materialize or I have time to >>think about a benchmark (Not likely anytime soon). >> >> > >That's ok. This discussion has been very fruitful on my end at least as >talking this out has helped me get a much better grasp on how this stuff >works on 4.x and should be done in 5.x to obtain at least somewhat similar >behavior. > well if you've worked it out,.. do let the rest of us know :-) I do think that there are several points that need work.. 1/ kse threads are ephemeral, and so they don't gather any 'history'. therefore it needs to be gathered somewher eelse.. (e.g. the ksegrp, but what does that actually mean?) 2/ what if the kg has both long-running and interractive threads? 3/ sibling thread affinity and how that affects priority and scheduling. We COULD store information in the mailbox.. but then we need to trust the user with it.. So then where do we store it? I have considerrred a store of 'cached' and "hashed" (like the buffer cache) sched-info structs that are recycled in a least-recently used manner.. when you get a thread with a mailbox you look for a sched-stats block corresponding with that mailbox address and use it.. if yu don't find it then you know that thread has not run for a long time.. so you grab the least-recently used one and recycle it as that thread hasn't run for a while. Basically the kernel could keep stats on behalf of the most active KSE threads in an efficient manner. The small stats structs would need to be only about 8 words.. (4 for 2 x doubel links. one for mailbox addr/key, and 3 for sched stats.) In effect the kernel keeps tabs on the most active user threads without the UTS knowing about it.