> Perhaps you could test total aggregate runtime for multiple processes
> with multiple threads, but I doubt this would be very interesting,
> since it's pretty obvious what the results would be simply from
> studying the SMP scheduler, whether there is CPU affinity, whether
> there is task group affinity, whether there is CPU thread group
> anti-affinity for balancing threads across CPU, etc., etc.. I'd
> expect a threaded program using user space threading and not
> explicitly yielding to other threads in the group to serially complete
> each thread, but to have a better agregate completion time because
> of the lack of process context switch overhead resulting from the
> kernel thread implementation of blocking system calls. Pointing at
> the obvious is rarely useful. 8-).
No You are just utterly wrong. What You are basically saying is: "There
can't be any conclusion from reasoning". Some time ago I had the occasion
to study the two level sceduler from Solaris (splitted between kernel and
user space). I can tell: It has much more overhead then the one used by
Linux. It *must* be therefore significantly slower.
Marcin
=========================================================================
In real life: System Programmer at AIS AXON GmbH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html