Subject: Re: Please Revert newlock2
To: None <email@example.com>
From: Bucky Katz <firstname.lastname@example.org>
Date: 02/18/2007 17:45:48
"Perry E. Metzger" <email@example.com> writes:
> Bucky Katz <firstname.lastname@example.org> 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
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.