From owner-freebsd-arch Wed Oct 9 22:28: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 3D7BB37B404; Wed, 9 Oct 2002 22:28:15 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB48B43E77; Wed, 9 Oct 2002 22:28:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx22-bradley.dialup.earthlink.net ([209.179.198.137] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17zVrp-0005AX-00; Wed, 09 Oct 2002 22:28:14 -0700 Message-ID: <3DA50FA4.3C8BE165@mindspring.com> Date: Wed, 09 Oct 2002 22:27:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Roberson Cc: arch@freebsd.org Subject: Re: Scheduler patch, ready for commit. References: <20021009211321.M23516-100000@mail.chesapeake.net> 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 Jeff Roberson wrote: > I haven't heard any objections to the goals of this patch. I have cleaned > it up and readied it for commit. This step is important so that I can > stop manually merging in new scheduler changes and get on with the new > scheduler. This patch does not change any functionality in the current > system. It is only a code reorg. > > As always any comments are welcome. The patch is available at > http://www.chesapeake.net/~jroberson/sched.patch THe documentation that you remove in kern_exit.c is not recreated anywhere. I think the XXX comments are important expository information. 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. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message