Date: Sun, 31 Oct 1999 23:31:40 -0500 (EST) From: Chuck Robey <chuckr@picnic.mat.net> To: Nate Williams <nate@mt.sri.com> Cc: Daniel Eischen <eischen@vigrid.com>, freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads goals version II Message-ID: <Pine.BSF.4.10.9910312324010.29073-100000@picnic.mat.net> In-Reply-To: <199911010421.VAA15119@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Oct 1999, Nate Williams wrote: > > > > > 6/ (contentious) multiple theads should be bound to within the resource > > > > > limits of the single process. > > > > > > > > Multiple processes/LWPs should be allowed to have their own quantum and > > > > not count towards the [parent] process quantum, right? > > > > > > As I read that, no. A multi-threaded process shouldn't be given any > > > more 'resources' than a single-threaded process. > > > > With the notable exception that a multithreaded process must be able to be > > concurrently running on multiple processors simpultaneously, right? > > I'm not sure. Once could argue that you get X% of the total CPU, which > means that if you're normally allotted 20%, a single-threaded process > would get 20% of a single CPU, and a threaded process might get 2x10% of > each CPU (depending on whether or not the threads need to be on multiple > CPU's, which may be the case.) > > It's an interesting problem.... I've been wondering what would be a practical minimum limit on the added information needed in kernel for kernel threads, and it seems that a count of runnable threads would be needed, and a count of thread blocks per quantum. If you had that, then you could see if there were just a few long running threads, and if a process was hogging processor time without any threads blocking, decrease the priority (like the present system). If there were a lot of blocks (much IO blockage) then I think I'd let the sucker go on, right? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- 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?Pine.BSF.4.10.9910312324010.29073-100000>