Date: Fri, 28 Mar 2003 09:21:11 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Jeff Roberson" <jroberson@chesapeake.net>, "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: Scott Long <scott_long@btc.adaptec.com> Subject: Re: 1:1 threading. Message-ID: <005201c2f4c8$517da320$f001a8c0@davidw2k> References: <20030327143259.I64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20 From: "Jeff Roberson" <jroberson@chesapeake.net> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: <arch@freebsd.org>; "Scott Long" <scott_long@btc.adaptec.com> Sent: Friday, March 28, 2003 3:50 AM Subject: Re: 1:1 threading. > On Thu, 27 Mar 2003, Daniel Eischen wrote: >=20 > > 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. >=20 > 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. >=20 > > > > > 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. >=20 > It didn't seem much easier to me. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 do you think that a multithreaded process should use more CPU time then a single thread process, so threaded process should have higher priority and block other single thread processes out? AFAIK, threading is not=20 designed for this, you may misunderstand what threading is designed for. > Cheers, > Jeff >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005201c2f4c8$517da320$f001a8c0>