From owner-freebsd-arch Sat Oct 12 12:20:14 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 8AA3C37B407; Sat, 12 Oct 2002 12:20:11 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA0843EB1; Sat, 12 Oct 2002 12:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021012192009.OIYB24595.sccrmhc02.attbi.com@InterJet.elischer.org>; Sat, 12 Oct 2002 19:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA64071; Sat, 12 Oct 2002 12:05:26 -0700 (PDT) Date: Sat, 12 Oct 2002 12:05:24 -0700 (PDT) From: Julian Elischer To: Hiten Pandya Cc: Terry Lambert , Jeff Roberson , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Scheduler patch, ready for commit. In-Reply-To: <20021012122510.A13430@angelica.unixdaemons.com> 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 Sat, 12 Oct 2002, Hiten Pandya wrote: > On Thu, Oct 10, 2002 at 01:18:44AM -0700, Terry Lambert wrote the words in effect of: > > > Yes, I agree, this is an important next step. I'm thinking that the > > > scheduler should indicate how much space is needed to the proc allocation > > > code. This much extra space could be allocated, and a pointer to > > > scheduler specific data could really be a pointer within that allocated > > > structure. This way it might be near enough for processor caches to be > > > effective. Clearly this needs more work. That is outside of the scope of > > > the current patch though. If done on the fly, this would require freeing all the allocated procs in the uma cache and changing the size of the zone, and re-filling it, and replacing all the existing procs with the new larger ones.. hardly a likely scenario. Pretty obviously the additional storage is in the form of an extra blobb hanging off the proc/kse/ksegrp/thread structures as needed. (Unless the scheduler can make use of a couple of void * 'p_sched_private' type fields we can preallocate. > > > > [...] > > You may actually want to look at the Solaris/SVR4 implementation, > > which supports both scheduling classes as loadable modules, and > > simultaneous multiple scheduler classes (SVID III(RT) and the > > "fixed" scheduling class, used to improve interactive response of > > the X server, as well as a batch scheduler, are included in the > > defaults for both systems). > > FWIW, the Solaris Internals book discusses this topic of scheduler > classes in detail, IIRC. It has been time since I touched the book. > > Cheers. > > -- > Hiten Pandya > http://www.unixdaemons.com/~hiten > hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@softweyr.com > PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message