Date: Thu, 10 Oct 2002 02:25:53 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jeff Roberson <jeff@freebsd.org>, <arch@freebsd.org> Subject: Re: Scheduler patch, ready for commit. Message-ID: <20021010022058.A23516-100000@mail.chesapeake.net> In-Reply-To: <3DA50FA4.3C8BE165@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Oct 2002, Terry Lambert wrote: > 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 tried to be careful about that. I guess I missed one. I'll throw it back in. Thanks! > > 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. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021010022058.A23516-100000>