Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Oct 2002 15:27:19 -0400 (EDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Julian Elischer <julian@elischer.org>
Cc:        Hiten Pandya <hiten@angelica.unixdaemons.com>, Terry Lambert <tlambert2@mindspring.com>, Jeff Roberson <jeff@FreeBSD.ORG>, <arch@FreeBSD.ORG>
Subject:   Re: Scheduler patch, ready for commit.
Message-ID:  <20021012152434.U30714-100000@mail.chesapeake.net>
In-Reply-To: <Pine.BSF.4.21.0210121201110.63899-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Oct 2002, Julian Elischer wrote:
> On Sat, 12 Oct 2002, Hiten Pandya wrote:
>
> > On Thu, Oct 10, 2002 at 01:18:44AM -0700, Terry Lambert wrote the words in effect of:
> > > > 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 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.
>

Is there really demand for on the fly scheduler changes?  I guess I always
thought of it as a neat trick and not something useful.  It doesnt seem
like it's worth the overhead  for the extremely small number of scenarios
where it's needed.

Cheers,
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?20021012152434.U30714-100000>