Re: 2.6.16-rc6-mm2

Keith Owens
2006-06-13T12:42:28Z

Andrew Morton (on Tue, 13 Jun 2006 04:45:32 -0700) wrote:
>On Tue, 13 Jun 2006 15:08:40 +1000
>Keith Owens <kaos@sgi.com> wrote:
>
>> Andi Kleen (on Tue, 13 Jun 2006 06:56:45 +0200) wrote:
>> >
>> >> I have previously suggested a lightweight solution that pins a process
>> >> to a cpu
>> >
>> >That is preempt_disable()/preempt_enable() effectively
>> >It's also light weight as much as these things can be.
>>
>> The difference being that preempt_disable() does not allow the code to
>> sleep. There are some places where we want to use cpu local data and
>> the code can tolerate preemption and even sleeping, as long as the
>> process schedules back on the same cpu.
>
>It would be easy to use this mechanism wrongly:

Agreed.

> thread 1 on CPU N thread 2 on CPU N
>
> foo = per_cpu(...)
> <preempt>
> foo = per_cpu(...);
> foo++;
> per_cpu(...) = foo;
> <unpreempt>
> foo++;
> per_cpu(...) = foo; // whoops
>
>
>In which scenarios did you envisage it being used?

There are not many scenarios where this makes any sense. One is where
the code is working on a collection of related cpu data and the whole
collection is protected by a per cpu mutex. Taking the mutex stops
your race. I doubt if we have any code like that yet.

The other possibility is to allow work to preempt the current process
while it spins in udelay(). This is a problem on systems that use the
cycle counter (TSC, ITC) and different cpus run at different rates.
See http://marc.theaimsgroup.com/?l=linux-ia64&m=113460274218885&w=2

I am not going to be too persistent about this facility. If it seems
too risky or of too little use, then forget it.