Date: Thu, 10 Jan 2002 14:40:48 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Kelly Yancey <kbyanc@posi.net> Cc: Alfred Perlstein <bright@mu.org>, Nate Williams <nate@yogotech.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: <3C3E1870.1E0DA81F@mindspring.com> References: <Pine.BSF.4.21.0201101401420.6961-100000@gateway.posi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kelly Yancey wrote:
> 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.
Remember that this is only true if someone is stupid enough to
use the FPU, which is only useful for very specific tasks, most
of which are non-threaded. For graphics and line drawing -- even
curve drawing -- the fast graphics world all uses integer math
and tables. That leave us with special purpose number crunching
that doesn't care incredibly deeply about its significant digits
running away to exponent&mantissa-land.
If a system call *is* required, it can be done conditionally
in a wrapper function that knows whether or not there's an
FPU in user space, or not.
> 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).
You could make a similar argument based on signal masks, which
are all overly complicated because the default signal behaviour
in POSIX is to *not* restart system calls. A much better idea
is to simply change the default behaviour, and the problem goes
away, outside the presence of a siginterrupt() call, or an sa_flags
explicitly clearing SA_RESTART, or a longjmp().
> 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?
No, Solaris *added* one around 2.4; see the comp.unix.bsd
archives, where I and a number of other people, including
Sun engineers, were discussing threads implementation
inefficiencies in Solaris/SVR4, starting in around 1993
and continuing for a number of years after that.
-- 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?3C3E1870.1E0DA81F>