Date: Thu, 10 Jan 2002 14:20:45 -0800 (PST) From: Kelly Yancey <kbyanc@posi.net> To: Alfred Perlstein <bright@mu.org> Cc: Nate Williams <nate@yogotech.com>, Terry Lambert <tlambert2@mindspring.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <Pine.BSF.4.21.0201101401420.6961-100000@gateway.posi.net> In-Reply-To: <20020110135324.N7984@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jan 2002, Alfred Perlstein wrote:
> * Nate Williams <nate@yogotech.com> [020110 13:52] wrote:
> > > I mean if we've got to go to the kernel to switch thread contexts, why
> > > not just have the kernel track all of the threads and restore context
> > > once, just for the current thread, rather than twice (once for the
> > > scheduler and another for the scheduler to switch to the current
> > > thread context)?
> >
> > For effeciency reasons...
>
> And flexibility as well, but I guess that can be lumped under
> effeciency.
>
If the context switch overhead is the same (or worse) with a userland
scheduler, then what are the "effeciency reasons" for having it? Where does
the userland scheduler reclaim it's lost ground? The only things my limited
understanding can produce are a number of trivial data structures that can be
moved from the kernel to userland. :/
It seems to me that if {get,set}context involve kernel calls, then any
userland scheduler would, by definition, require N+1 context switches where N
is the number of context switches required by a kernel-only scheduler. The
extra 1 coming from invoking the scheduler context itself.
The flexibility argument I can buy, given as a trade-off of performance
versus flexibility. However, I do not see where having a mixed
kernel/userland scheduler can be both more flexible and more efficient in the
case that it requires a syscall to switch userland contexts. And it doesn't
seem proper to keep the flexibility argument if {get,set}context only work
with our specific implementation of libc_r (as Peter has already noted).
Of course, all this moot if userland context switches can be done properly
without entering the kernel and in a way the preserves flexibility.
As an aside, I cannot find a reference now, but hasn't it been rumoured that
Solaris has dropped it's userland scheduler?
Kelly
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?Pine.BSF.4.21.0201101401420.6961-100000>