Date: Fri, 5 Nov 1999 23:00:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: tlambert@primenet.com, eischen@vigrid.com, julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <199911052300.QAA07809@usr06.primenet.com> In-Reply-To: <199911050048.QAA49642@rah.star-gate.com> from "Amancio Hasty" at Nov 4, 99 04:48:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > One could argue that the program should be using a hybrid scheduling > > class in the kernel in order to achieve this effect, rather than > > having to have the idea that you would want to schedule seperate > > kernel schedulable entities within one program. > > How to you propose to handle priorieties for different > "thread thingies" --- "thread thingies" being a yet to > be defined thread implementation. You mean how will a user space scheduler implement the user space scheduling class that handles pthread_attr_setschedpolicy(3) calls? Or do you mean something deeper, such as "since I'm already thinking in terms of kernel threads, how will you let me set kernel scheduling policy for kernel threads, if there aren't any?". > What I am think is that for whatever reason there are applications > which want threads to be running at different priorities for instance > "Kaffe" wants or needs threads running at different priorities. That's no problem for any model, so long as you are talking threads priorities, rather than process priorities. If you are talking process priorities, well, then you're assuming something you shouldn't assume about the underlying implementation because POSIX doesn't give you permission to assume it. 8-). That's not to say that we might not want to implement a user space scheduler assist that can make modifications to which per CPU ready-to-run queue that kernel scheduling contexts take place in, but in my view migration between processors is a user space scheduler decision, based on what ready to run vs. where it ran last vs. what CPU is returning up into user space. I really can't see any other way that the kernel scheduler could know what would or would not be a cache bust, since it's so tightly bound to the particular program implementation; the kernel scheduler is a poor substitute for The Great Karnak. 8-). I'd really like to look at the kernel scheduler as nothing more than something that can hand out resources, and that a quantum is a resource, and that concurrent quanta are an artifact of SMP, and whether or not you get concurrent quanta is totally seperate from your policy decision about which thread in user space gets to run when you have a quantum in hand. Kind of like Linus (Lucy's brother, not Torvalds) and The Great Pumpkin: the quantum comes to visit a thread if it's in the most sincere process. Multiple CPU's bear the same resemblence to the quantum fairy as Elves bear to Santa Claus. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199911052300.QAA07809>