From owner-freebsd-arch Thu Oct 10 10:32:46 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 3E86237B401 for ; Thu, 10 Oct 2002 10:32:45 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0586F43EB1 for ; Thu, 10 Oct 2002 10:32:41 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 583872A88D; Thu, 10 Oct 2002 10:32:37 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Jeff Roberson Cc: arch@freebsd.org Subject: Re: Scheduler patch, ready for commit. In-Reply-To: <20021010022058.A23516-100000@mail.chesapeake.net> Date: Thu, 10 Oct 2002 10:32:37 -0700 From: Peter Wemm Message-Id: <20021010173237.583872A88D@canning.wemm.org> 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 Jeff Roberson wrote: > On Wed, 9 Oct 2002, Terry Lambert wrote: > > I'm somewhat concerned that you go to all this trouble, and then > > don't seperate out the statistics data from the proc structure; > > this probably means pushing the allocation of the proc structure > > into the scheduler code, if it's supposed to be one lump, but it > > should be just as easy to allocate it seperately with an encapsulated > > allocation that allocated the scheduler part, the proc part, and then > > aggregates them, all protected by the proc lock, and then imply that > > the proc lock protexts the data (since they will never divorce, even > > on deallocation, because the proc structs go to a free list, unless > > the memory is freed back to the system). I rather expected the > > statistical data, which is algorithm dependent, to be broken out. > > > 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 you're going to do this, a low impact way to do it might be do to what the pcpu stuff does and what vm_page_t does to insert MD fields into a MI structure. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message