Date: Sat, 28 Oct 2006 01:34:30 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: David Xu <davidxu@freebsd.org>, freebsd-current@freebsd.org Cc: Daniel Eischen <deischen@freebsd.org>, Julian Elischer <julian@elischer.org>, "Alexandre \"Sunny\" Kovalenko" <Alex.Kovalenko@verizon.net> Subject: Re: Comments on the KSE option Message-ID: <p06240825c16893d0698a@[128.113.24.47]> In-Reply-To: <200610281206.13588.davidxu@freebsd.org> References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> <200610281206.13588.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:06 PM +0800 10/28/06, David Xu wrote: >On Saturday 28 October 2006 11:51, Julian Elischer wrote: > > Alexandre "Sunny" Kovalenko wrote: > > > > > > I apologize for misinterpreting your words. But then, if I have > > > M:N set to 10:1, I would expect application with 1000 process > > > scope threads to have as many CPU slots as 100 processes, or, > > > if I have 10 system scope threads and 990 process scope threads, > > > I would expect application to have as many CPU slots as 109 > > > processes. Is this what you refer to as "fairness"? > > > > M:N is not a ratio, but rather the notation to say that M user > > threads are enacted using N kernel schedulable entities (kernel > > threads). Usually N is limited to something like NCPU kernel > > schedulable entities running at a time. (not including sleeping > > threads waiting for IO) > > (NCPU is the number of CPUs). > > > > so in fact M:N is usually M user threads over over some number > > like 4 or 8 kernel threads (depending on #cpus) plus the number > > of threads waiting for IO. > > >> Julian > >As you are emphasizing fairness, I must say I don't believe fairness >in libpthread either, I don't think writting a fairness scheduler is >an easy work, does kernel have made fairness for threads in same >ksegrp, so does libpthread's userland scheduler ? they don't, it can >make threads in same ksegrp misbehaviored, so what we have done is >still process scheduling fairness even there is ksegrp in kernel, >and now sacrificed fairness between threads. I think we have different ideas of what is the goal is with this claim of "fairness". If I understand it right, it is *not* that some static code in the kernel is going to decide which applications are fair and which ones are not fair. IIIRC, what Julian wants to do is provide a way that the administrator can make that decision. The administrator will have a way to throttle some thread-crazy process, but only if the *administrator* wants to do that. If the machine is for a single user, then that user will probably set "N" to a high value. But if the machine has a lot of users on it, then the administrator of that machine may want to set "N" to the number of CPU's on the system, or maybe the number of CPU's minus 1. And if the users don't like that, then they can go buy their own damn machine instead of using the machine someone else bought and is allowing them to access for free. At RPI we have both kinds of machines. Machines owned by a single user, and machines which have multiple students ssh'ed into at the same time. I can see wanting to throttle thread-crazy processes on some machines, and not wanting any throttling at all on others. ...but it has been a few years since the presentation that I remember Julian giving about this, so maybe I am not remembering it correctly. I do remember that whatever it was, it sounded pretty reasonable at the time. :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06240825c16893d0698a>