[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: revivesa status 2008/07/09
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
Once SA is merged it will be easy to measure.
Main Index |
Thread Index |