Re: revivesa status 2008/07/09

[christos%astron.com@localhost (Christos Zoulas)]

In article <20080712104426.89CD863B1AA%mail.netbsd.org@localhost>,
Mindaugas Rasiukevicius  <rmind%NetBSD.org@localhost> wrote:
>Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
>> I think there's another significant benefit: it should give a significant,
>> possibly even huge, performance benefit for multithreaded applications on
>> platforms which are uniprocessor and have a significant penalty for
>> context-switching into the kernel.
>
>Would not be so sure about significant performance benefit. Can you provide
>a practical application where SA outperforms 1:1?

Yes, on a uniprocessor an application that has many threads and does not
do a lot of kernel waiting will always beat 1:1 just because it does not
have to use the kernel to context switch.

>Theoretically, I see some quite specific cases where SA may perform good,
>but doubt that in real, practical world such cases have a use, or if have,
>I believe there are other ways to achieve the same without SA (as we are
>talking about workload based in the user-space).
>
>Note that multithreaded applications usually need synchronisation, which
>likely involves blocking, otherwise - I am not sure why engineer have chosen
>the multithreaded way in specific UP system for CPU-only workload.
>
>> The obvious example is ARM -- and there are a _lot_ of ARM CPUs out
>> there in the world in embedded devices, often running software that makes
>> heavy use of threading for its UI.  There are pretty well-understood reasons
>> why SA actually does win in this kind of use case, and it's not an
>> unimportant one for NetBSD.
>
>Well, it is "well-understood" in theory. SA was a kind of nice idea from
>theoretical perspective, but was not proven practically in any relevant
>environment and system. At least two systems which tried migrated to 1:1.

Let's not confuse N:M to SA. Which other system do you know that used SA?

>Also, you have mentioned "threading for its UI", what usually means a lot of
>blocking (and/or synchronisation), so it is not a workload for SA.
>
>> If I saw a benchmark -- and not an I/O bound one -- from such a platform
>> where the 1:1 threading did anywhere near as well as the SA threading I'd
>> certainly change my mind, but...
>
>Perhaps you can give us a link to that benchmark which would show how SA
>performs better than 1:1? There were many benchmarks which proven 1:1
>performance, but unfortunately I have not seen any benchmark where SA
>performs better than 1:1 on NetBSD.
>
>It is easy to say "well-understood", "obvious", "saw". But perhaps we can
>be more constructive by providing numbers, test-applications, or something
>like that?

Once SA is merged it will be easy to measure.

christos