Re: 2.6.16-rc6-mm2

[Keith Owens <kaos@sgi.com>]

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/