"Perry E. Metzger" <perry@piermont.com> writes:

> 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.

For our purposes "Make M:N work correctly again" amounts to ifdefing
the kernel code to compile the already-working M:N for a uniprocessor
as a conf option.

Unless y'all have never done anything at all to optimize syscall
paths, that's going to be a _lot_ easier than trying to make up for
the performance loss by finding improvements in syscall paths.