Date: Thu, 10 Jan 2002 16:52:33 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Kelly Yancey <kbyanc@posi.net>, Alfred Perlstein <bright@mu.org>, 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.10561.770884.650901@caddis.yogotech.com> In-Reply-To: <3C3E264D.1BBB513@mindspring.com> References: <Pine.BSF.4.21.0201101401420.6961-100000@gateway.posi.net> <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com> <15422.8123.659620.421602@caddis.yogotech.com> <3C3E264D.1BBB513@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Are we maybe bringing this on ourselves? It seems to me that we
> didn't have this huge \discussion until we started trying to jam
> everything to do with a thread context switch into {get|set}context
> calls, which was assumed couldn't be hybrid, and had to either be
> always user space or always kernel space.
Not quite. The reason for this discussion is because Dan wanted someone
to review his get/setcontext library functions, and we wanted to make
sure they did the right thing in *all* cases.
Alfred's point was that if it were possible to make the FPU context
save/restore not done *everytime* (aka lazy binding), we should consider
it.
The rest of the discussion is everyone else jumping in trying to
understand the issues, and taking it on weird tangents like whether or
not threads are appropriate, etc...
> I've assumed that FPU usage is uncommon, and that optimizing for
> the non-FPU case still makes the idea a win. I might be wrong.
Based on my experience porting a userland thread scheduler, you're way
off base. :)
> Are we to the point where we should question user space
> scheduling entirely?
Again, now you're forcing your world view on others. Bad Terry, no
cookie!
> The point was (after activations made things a bit more
> complicated) to ensure that we don't pay a heavy context
> switch overhead
On that note, is the overhead of a system greater than the overhead of
saving the FPU context? Also, even *IF* we save the FPU context for
every userland context switch, is it *still* a lighter-weight switch
than performing a kernel context switch.
And, even if both answers are 'no', by providing a userland threading
library, we allow people to write portable code that may not be as
effecient as something else *right now*, but will have the potential to
be much more effecient with KSE's (on single and/or multi-processor
systems).
The above feature is more than enough to justify keeping the existing
functionality in FreeBSD.
> Full quantum utilization is also an obvious win, since if
> you can achieve it, you've gone most of the way to elimiating
> the overhead that the original design goals of threads in the
> first place were trying to eliminate.
This is (one of many) reasons to keep userland threads.
> So I guess the question of whether or not we need an incredibly
> heavy context switch overhead in most cases remains?
Define incredibly heavy? Is a kernel process switch 'heavier' than a
userland context switch (including the FPU state)?
And, I'd appreciate that you'd leave your assumptions/opinions about
what *should* be done out of the discussion. It irrelevant, and only
serves to distract the discussion from it's real purpose.
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.10561.770884.650901>