Date: Sun, 28 Nov 1999 13:54:55 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Julian Elischer <julian@whistle.com>, arch@freebsd.org Subject: Re: Threads stuff Message-ID: <38417A7F.B23C701D@vigrid.com> References: <Pine.BSF.4.10.9911271542410.544-100000@current1.whistle.com> <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > Problems: > > * You have to manage dynamic allocation and deallocation of KSE's > (verses simply preassigning one per thread). > > * You have non-deterministic resource utilization for an application. > The worst case KSE useage is going to be one per thread, but the > userland may well allow thousands of threads to be allocated first > and then realize only later that it does not have the kernel > resources to block in all of them at once, leading to > non-deterministic blockages. > > * You compound the management issues within the userland scheduler > itself because not only can the userland scheduler switch between > threads, now so can the kernel when it decides it must block. > (this is an argument to have a kernel entry point to schedule a > thread no matter what). I'm starting to agree with you on this. If you take into account that the UTS needs to set up a scheduling signal/upcall whenever a thread switch occurs, then why not have one system call that both switches to a new thread and sets up the scheduling signal. > > * The userland scheduler has no concept of certain types of blockages, > such as VM faults, and cannot schedule around such things itself. > This can lead to non-deterministic operation. The UTS can treat a page fault in the same way as a blockage on I/O (unless the page fault occurs in the scheduler itself). A new thread can be chosen and run, and the UTS can be notified when the page fault is cleared. > * The userland scheduler must deal with scheduling the N cpu case > itself - this is something more suitable to the kernel because the > userland scheduler has no knowledge of other unrelated > processes/threads running in the system. This means that > if the userland scheduler is trying to switch or schedule threads > without making a system call, the whole mess becomes much more > complex when the kernel winds up having to manage the same > threads itself. I think the UTS need only concern itself with its own allocated subprocesses. It multiplexes threads onto processes, and it's the kernels job to multiplex processes onto CPUs. I think I do agree with you on having to make a system call to switch threads, but I'm not completely off the fence yet ;-) > This isn't to say that the userland scheduler cannot choose a > loosely (or hard) bound cpu for a thread, only that the kernel is > better able to actualy get the thread running deterministically > because the userland scheduler might end up 'stuck' in a VM > fault or something similar. > > I am beginning to warm to the dynamic KSE concept but I think the only > way to avoid unnecessary complexity AND to avoid potential resource > sharing problems is to impose two requirements: > > * First, that thread runnability be controlled through a system call. > Ther userland can determine when to halt and run a thread and can > even assign a cpu, but it must make a system call to actually > schedule or deschedule the thread. Do we really want to be able to bind a _thread_ to a CPU? Wouldn't it be sufficient to be able to bind a process to a CPU? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38417A7F.B23C701D>