Date: Thu, 27 Mar 2003 14:50:56 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Scott Long <scott_long@btc.adaptec.com> Subject: Re: 1:1 threading. Message-ID: <20030327143259.I64602-100000@mail.chesapeake.net> In-Reply-To: <Pine.GSO.4.10.10303271132290.25558-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Mar 2003, Daniel Eischen wrote: > On Thu, 27 Mar 2003, Scott Long wrote: > > Once 5-STABLE happens, users of 5.x can no longer be guinea pigs for KSE > > development. By keeping the 1:1 and M:N API's separate, KSE can > > progress in 6-CURRENT until it is proven while still allowing MFC's to > > 5-STABLE to happen without too much pain. > > That's kind of silly; we have other ways to keep API/ABI > compatability and have used this for all other syscalls. > The KSE and thread mailboxes even have version numbers > in them. Which means they are likely to change. I do not want to develop on unstable APIs and unstable kernel code. kern_thr.c is 254 lines. I think we can handle a little duplication. I'm not sure why the objection is so strong. > > > Later on down the road when > > KSE matures, or when we decide that 1:1 should really just be a special > > case of M:N, we can look at addressing the above concerns and possibly > > MFC'ing the results back to 5-STABLE. But for now we need to allow for > > 5-STABLE to actually be usable and maintainable. > > The libthr implementation of 1:1 is not what most consider > 1:1 -- you don't get a separate quantum and priority for > each thread. As such, this library is really no different > than libkse. The only real difference is that the UTS > chooses the next thread to run instead of the kernel. > If you're going to add a bunch of code to both userland > (in libthr) and the kernel just to get a working threading > library, it seems much easier to just fix libkse so that > it works for the single KSE/KSEG case. It didn't seem much easier to me. This whole argument about kseg/kse/thread vs kse/thread can be solved very easily by allocating a ksegrp in kern_thr.c I estimate that would add another 10 lines of code. The ksegrp argument is questionable anyway. In both ULE and 4bds each KSE gets its own quantum. The KSEGRP holds the static priority and the dynamic user priority which is calculated based on the behavior of the whole process. This causes all threads in the process to be penalized for using cpu at the same rate as a single threaded process using an equivalent amount of cpu would be. The effects are less because each thread/kse is given as big of a quantum as each full process would. I'm not sure if this is a bug or a feature. In my opnion the ksegrp is not totally hashed out. I think you may forget that I have done a fair amount of work on schedulers in freebsd and I do understand the ramification of the decision that I made. I do not think this at all important to have correct prior to having real users using real threads. Cheers, Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030327143259.I64602-100000>