Date: Thu, 10 Jan 2002 15:39:57 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: 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: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote:
> > There are several real reasons for threading, and a lot of bogus
> > ones.
>
> The world is bigger than your ideas of what is acceptable or not.
I didn't say it was unacceptable, I said it was frequently bogus,
which is very different.
> Forgive me if I refuse to bow down before your almighty knowledge, or
> your twisted world view on what deem to be valid use of threading.
Let me ask another way: What are the design goals behind
threads implementations?
Threads predate SMP, so it can't just be "SMP scalability";
in fact, we have to admit that "SMP scalability" is very much
an afterthought, because of negaffinity and L1 cache coherency
issues.
> > I'm not saying that the FPU shouldn't be used by people who
> > have need of it (e.g. people unable to download integer SIN
> > and COS tables, for example... 8-)), but I *am* saying that
> > if there is no way around a kernel entry for a threads context
> > switch because of the frigging FPU context, then only the
> > programs actually using the FPU should pay that penalty.
>
> I don't think you'll get an argument from *ANYONE* on that point.
> However, it may not be possible to do that with the current x86
> architecture. The above statement is the crux of this entire thread.
Ugh. I hate that idea. I have a very hard time believing it.
I'm liking the idea of causing a fault by disabling the FPU
until it is first used more and more...
> I disagree completely. Threading provides lots of things besides SMP
> scalability. Inter-process/inter-thread communication is almost
> inherently more effecient with threads, plus it vastly more portable.
I'll agree to disagree here...
> Additionally, certain algorithms/problems lend themselves very well to
> multiple threads.
And I'd be willing to challenge you on an algorithm vs. problem
fit on a one by one basis, here.
> Yes, they it may be possible to done them more effeciently with finite
> state machines, but if we're going down that road, why not write
> everything in assembler.
??? I think the difference is whether your thread local storage
and/or things you keep on your thread stack get put into a single
instance state structure, or not. It usually has more to do with
whether you wrote your code to solve a problem after having thought
about it up front, or you hacked and hacked until it worked.
> There are lots of great reasons to use threads, in the same manner as
> there are lots of *great* reasons not to use threads. However, about
> 80% of the software that is written using threads (or C, or Lisp, or
> C++, or OOP programming, etc..) could just as easily be written with any
> other myriad of programming languages/methodologies.
Or not using threads, yes... there's always another way to solve
any problem. Before this discussion devolces into paredo optimal
approaches for N-P complete problems, though, we probably ought to
be asking how we can avoid the FPU context switch overhead.
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.
In fact I remember a certain person (*cough* me) that suggested
that because of SPARC it had to be kernel space... I was (*cough*
happily) corrected on "flushw" (assuming that we are never going
to run in my old 32 bit SPARC box in the other room).
> I'm finding that it's the quality/experience of the programmers that
> makes more of a difference than the technology being used. So, a
> program that is perfectly suited to using threads could still be a mess
> if written by the wrong guy, while one that isn't well-suited to threads
> blows the doors off most every other program when written by someone who
> is well-versed in threaded programming.
Mirrors my experience, too, FWIW...
> Bottom line. It's not for us to decide what is/isn't appropriate to do
> inside of a threaded program. It's up to us to make sure we make our
> first priority is to make the program run correctly, and secondly run as
> effeciently as possible.
Well, maybe we need to go back and question even more assumptions
than I've suggested above...
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.
Are we to the point where we should question user space
scheduling entirely?
The point was (after activations made things a bit more
complicated) to ensure that we don't pay a heavy context
switch overhead, need to unnecessarily complicate the
scheduler for thread group affinity (the Linux/Dynix/IRIX
per CPU scheduler fixes that last one), to fully utilize
the quantum, and to lazy-create contexts for blocking
calls that might not otherwise be necessary.
I think these last two are still valid reasons, no matter
what: there are system calls that don't require blocking,
like "getpid()" or "getppid()", so having blocking context
for each and every call (like Linux does) is patently
absurd.
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.
So I guess the question of whether or not we need an incredibly
heavy context switch overhead in most cases remains? I'll step
back and let people make their cases based on the FPU-ness of
programs (my base assumption should be clear by now: FPU-ness,
IMO, is the exception, not the rule).
-- 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?3C3E264D.1BBB513>