From owner-freebsd-arch Fri Sep 20 14:20:16 2002 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 3C3D037B401 for ; Fri, 20 Sep 2002 14:20:14 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC3D43E42 for ; Fri, 20 Sep 2002 14:20:13 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020920212012.PCLG28420.sccrmhc03.attbi.com@InterJet.elischer.org>; Fri, 20 Sep 2002 21:20:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA20892; Fri, 20 Sep 2002 14:12:17 -0700 (PDT) Date: Fri, 20 Sep 2002 14:12:16 -0700 (PDT) From: Julian Elischer To: Rik van Riel Cc: Bill Huey , freebsd-arch@freebsd.org Subject: Re: New Linux threading model In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 20 Sep 2002, Rik van Riel wrote: > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > I didn't sat it's not possible, it's just that the interaction between > > threads and KSEs on the run queue is very complicated in the current > > "interim" scheduler (compatible with the old process scheduler but with > > a huge "tumor" on the side of it to do something with threads) > > > ie. You need to schedule threads in the kernel, while not allowing > > a process with a lot of threads to flood the system. > > Interesting problem, but that might be better done in a more > generic way. Ie. first build a thread scheduler and then add > support for generic resource containers that aren't tied to > the thread<->process relation. > > Once you have that, you could substitute thread<->user for the > default relationship and prevent users with many threads from > flooding the CPU ;) > > Adding resource containers to a scheduler can be hard though, I > still haven't found a pretty way of adding per-container (in my > case I want to start with per-user) CPU time accounting to Ingo's > O(1) scheduler. Sure, I've got several ugly ideas and one less > ugly idea, but I haven't found anything nice yet... Yes this is one of the possible solutions.. FreeBSD has not tackled the problem yet. All that has happenned is that I have refactored the proc struct in as flexible a way as I can (it's now 4 pieces) that can be reassembled in different combinations to produce every variant I have seen in the literature. glob them ALL together to get UNIXtreat proc and ksegrp as one, and kse and thread as one and get MACH threads. put proc and ksegrp together, and tread thread and kse as separate, and you get scheduler activations. put the thread and KSE and KSEGRP together vs the proc, and you have solaris LWP. What we now need is a "scheduler weenie" to start using these and playing with them to produce some good algorythms. What we have in place now is a 'simplest compatible scheduler' that handles UNIX processes as before, but can schedule threads independently. It's by NO MEANS optimal. > > regards, > > Rik > -- > Bravely reimplemented by the knights who say "NIH". > > http://www.surriel.com/ http://distro.conectiva.com/ > > Spamtraps of the month: september@surriel.com trac@trac.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message