From owner-freebsd-arch@FreeBSD.ORG Thu Mar 27 17:19:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2F8737B407 for ; Thu, 27 Mar 2003 17:19:57 -0800 (PST) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CC3343FA3 for ; Thu, 27 Mar 2003 17:19:55 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HLDQ3B6M; Fri, 28 Mar 2003 09:06:22 +0800 Message-ID: <005201c2f4c8$517da320$f001a8c0@davidw2k> From: "David Xu" To: "Jeff Roberson" , "Daniel Eischen" References: <20030327143259.I64602-100000@mail.chesapeake.net> Date: Fri, 28 Mar 2003 09:21:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: arch@freebsd.org cc: Scott Long Subject: Re: 1:1 threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2003 01:19:59 -0000 ----- Original Message -----=20 From: "Jeff Roberson" To: "Daniel Eischen" Cc: ; "Scott Long" 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"