Subject: Re: upcalls?
To: Noriyuki Soda <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 12/08/1999 16:36:58
Noriyuki Soda <firstname.lastname@example.org> writes:
> > Macrokernels like NetBSD just don't work this way. If you were, e.g.,
> > to create what we'll call a `NetBSD kernel thread' every time a
> > process/thread blocks, the overhead would be so amazingly bad that the
> > thread implementation would be useless.
> As I wrote previous mail, this overhead could be workarounded by
> thread buffering. So this is not problem.
Only partially. It does *not* solve the memory usage issues
(currently 8.5k or so per blocked `thread', minimum). Nor does it
solve more subtle issues (such as bad cache behavior from switching
kernel stacks all the time) that Mach solves. Solaris does this
partially via `turnstiles'.
> > Solaris/SVR4 does *not* work this way. The activation state is saved
> > by the thread library and then freed; it does not persist for the
> > duration of the block. In the normal case, a threaded program on
> > Solaris has at most one LWP (which corresponds with a `NetBSD kernel
> > thread') per processor, and no more.
> Hm, now I seem to know where you misunderstood.
> Until Solaris 2.5, Solaris's thread implementation works as you
> But since Solaris 2.6, the implementation is changed from the above
> way to scheduler activations, because scheduler activations is better
> about performance than above way.
> SGI IRIX and Compaq Tru64 UNIX have been switched to scheduler
> activations before Solaris (because of performance reason).
I don't have any data on this, so I can't comment on it.