Date: Wed, 29 Sep 2004 17:00:36 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: Stephan Uphoff <ups@tree.com> Subject: Re: sched_userret priority adjustment patch for sched_4bsd Message-ID: <Pine.GSO.4.43.0409291646040.15102-100000@sea.ntplx.net> In-Reply-To: <415B1DD9.2050409@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Sep 2004, Julian Elischer wrote: > > > John Baldwin wrote: > > > > >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. Remember that the UTS (IAW POSIX) should be in charge of which threads run _within_ a process. Across processes, and for system scope threads, that's another story. I think it would be cool if the UTS could store its version of priority in the thread mailbox, and the kernel would use this as a hint for which threads should get worked on when blocked in the kernel. For instance, if a thread is currently running with high priority and it makes a system call, that's a chance for the kernel to continue other blocked threads. But if the other blocked threads are all of lower (UTS) priority, you might not want to continue them (or upcall) when the currently running thread has a higher priority. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0409291646040.15102-100000>