Date: Thu, 27 Mar 2003 15:09:48 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Scott Long <scott_long@btc.adaptec.com> Subject: Re: 1:1 threading. Message-ID: <Pine.GSO.4.10.10303271456430.24745-100000@pcnet1.pcnet.com> In-Reply-To: <20030327143259.I64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Mar 2003, Jeff Roberson wrote: > 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. I don't see kse_create() changing since it takes a mailbox pointer as an argument and you can theoretically hang anything off the [versioned] mailbox. > > > 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. For the single KSE/KSEG case it's almost there. There are just a couple of issues involving signals and some bugs. It's basically libc_r with the UTS swapped out for a KSE-one. I haven't spent any time on it because I wanted to come at it from a different angle; rewriting it with KSE/KSEGs in mind instead of just porting it. > 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. That wasn't my understanding of how KSE's were suppose to work. The orignal idea was that the quantum and priorities were suppose to be in the KSE Group. Yes, two KSEs could get scheduled simulataneously on different CPUs and consume 2 quantums, but the KSE Group would get charged for both causing them to run less often. Or something like that. In effect, over time 2 KSEs in a group would get no more processor time than a non-KSEd process (all other things being equal). I originally argued that it didn't make sense to have both a KSE group and a KSE; that they could be one and the same. I lost the argument :-) -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10303271456430.24745-100000>