From owner-freebsd-arch Sat Oct 12 13:47:26 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 ABE6637B401; Sat, 12 Oct 2002 13:47:24 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43CA143EAC; Sat, 12 Oct 2002 13:47:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0083.cvx21-bradley.dialup.earthlink.net ([209.179.192.83] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 180TAM-0004Yd-00; Sat, 12 Oct 2002 13:47:18 -0700 Message-ID: <3DA88A09.12402F6C@mindspring.com> Date: Sat, 12 Oct 2002 13:46:01 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Hiten Pandya , Jeff Roberson , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Scheduler patch, ready for commit. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > > > > 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. This is actually Jeff you are quoting here... > 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. Yes. The point is to encapsulate the allocation, so that it occurs in the context of a scheduler. By doing that, you permit the proc lock to protect both the proc struct, and the "blob" pointed to by the proc struct. What this boils down to is asking a scheduler for a new process that it manages, as opposed to asking the system for a process, and then assigning it a scheduler. This is consistent with "inherit on fork" semantics. Initially, you could preclude migration of control between schedulers of individual processes: it's something you could handle later. Note that any migration is going to have different measures, so it's not like you are going to be able to translate a measure between one and the other, and have the second scheduler class pick up as if the proc had always been running under it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message