On Feb 18, 2007, at 11:22 AM, Perry E. Metzger wrote:

>
> Bucky Katz <bucky@picovex.com> writes:
>>> 2) Either cause them to perform acceptably for your application,  
>>> or else
>>>    endeavor to get M:N back in a supported state for uniprocessors.
>>
>> It has to be the later. The context switch overhead of 1:1 on ARM  
>> will
>> cause a severe performance degradation.
>
> I'm not sure about that. The experience of Solaris and other unices
> has been that a tuned 1:1 isn't that bad, whereas M:N is very hard to
> make work correctly. It might be easier to tune 1:1 for ARM than to
> make M:N work correctly again. A little effort spent on speeding up
> the system call path and the scheduler could pay off quite handsomely.

Note that we can have a M:N without SAs.  Any time a pthread sleeps  
inside libpthread due to a timed sleep, a blocked mutex, or waiting  
on a condition there is no reason why that pthread needs a LWP behind  
it.  That's why we have the new LWP syscalls _lwp_park and  
lwp_unpark.  The more LWPs a process has, hopefully, the less likely  
that a large will be runnable at any one time.

One thing we are missing right now (as far as I can tell) is a way to  
have processor affinity for a LWP.  While affinity shouldn't normally  
be used, sometimes it is required.