Date: Thu, 10 Jan 2002 15:44:51 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kelly Yancey <kbyanc@posi.net>, 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: <15422.6499.274704.270810@caddis.yogotech.com> In-Reply-To: <3C3E1870.1E0DA81F@mindspring.com> References: <Pine.BSF.4.21.0201101401420.6961-100000@gateway.posi.net> <3C3E1870.1E0DA81F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Huh? Methinks Terry needs to make assume the world is just a *teeny*
bit larger than his narrow-view.
> 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.
Even simple statistics use FP math. You're implying that FPU should
only be used by folks who have a real *NEED* for it, which is humerous
considering you're the one who usually bangs on the drum to make FreeBSD
useful for more folks. :)
Nate
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?15422.6499.274704.270810>
