Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Oct 2002 01:18:44 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        Jeff Roberson <jeff@freebsd.org>, arch@freebsd.org
Subject:   Re: Scheduler patch, ready for commit.
Message-ID:  <3DA537E4.274A3714@mindspring.com>
References:  <20021010022058.A23516-100000@mail.chesapeake.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote:

[ ... seperate out scheduler specific proc struct gunk ... ]

> 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.

I understand that, but it means that it leaves data interfaces
lying around; to be completely abstract, everything has to be
procedural, with data references occurring via accessor/mutator
functions.  If the point is to create the abstract interface,
then you probably want to be thorough.

As far as throwing it to the proc allocation code, to allocate
the proc struct and the data as a single lump, that's probably
*not* a good idea, unless there is a scheduler specific allocation
and free function ("new/delete").

The reason is that it's a short step from having an abstract
interface to supporting multiple scheduler classes simultaneously
in the same system.

You may actually want to look at the Solaris/SVR4 implementation,
which supports both scheduling classes as loadable modules, and
simultaneous multiple scheduler classes (SVID III(RT) and the
"fixed" scheduling class, used to improve interactive response of
the X server, as well as a batch scheduler, are included in the
defaults for both systems).

-- 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?3DA537E4.274A3714>