Date: Sat, 12 Oct 2002 13:46:01 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Hiten Pandya <hiten@angelica.unixdaemons.com>, Jeff Roberson <jroberson@chesapeake.net>, Jeff Roberson <jeff@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Scheduler patch, ready for commit. Message-ID: <3DA88A09.12402F6C@mindspring.com> References: <Pine.BSF.4.21.0210121201110.63899-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA88A09.12402F6C>