Date: Tue, 04 Jul 2006 21:57:51 -0700 From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? Message-ID: <44AB46CF.9030503@elischer.org> In-Reply-To: <200607050724.18740.davidxu@freebsd.org> References: <20060703101554.Q26325@fledge.watson.org> <44AAC47F.2040508@elischer.org> <200607050706.33502.davidxu@freebsd.org> <200607050724.18740.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: >On Wednesday 05 July 2006 07:06, David Xu wrote: > > > >>Cann't solaris's user usage scheduler will solve the problem ? if I >>recall it correctly, the decay factor in 4bsd scheduler can be changed >>dynamically for a thread, the decay factor can be stored in thread >>structure, and timeslice can be dynamically changed, also can be in thread >>structure, unlike current implementation, timeslice is fixed, this may >>make fair scheduling possible without ksegrp. >> >>Also will the roundrobin callout preempt a thread ? if that's true, then >>when every timeslice tick, a thread exhausted its timeslice is put at head >>of runqueue, isn't it a bug ? the callout is somewhat random for a thread, >>might not be a problem... >> >> > >OK, I just digged out the paper in my disks, here is the reference: >http://people.freebsd.org/~davidxu/doc/solaris2.pdf > >[the address thread@freebsd.org is removed] > >I think we really should do more work in kernel scheduler, and remove >ksegrp. > > the original aim for the ksegrp was not for fair scheduling but to allow libraries to instanciate their own threads in a way that they did not impact the application's threads in any way. Effectively, running them in their own process.. Fair scheduling just made use of it as a convenient abstraction. Removing the ksegrp entirely just reduces everything down to being boring threads with no possibility of ever doing anything different. KSEs have already gone, except as a scheduler abstraction. and having KSEGROUPs shouldn't affect anything negatively from no on. though they could be renamed threadgroups now. The scheduler complexities we see now do not come from having ksegrps, but rather, from trying to do fair scheduling in the rather simplistic "obvious" manner that I did. I am truely surprised that someone has not come up with a better way to do it by now. I was expecting that the current approach would have been replaced by something more sophisticated by now. >David Xu > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AB46CF.9030503>