Messages in this thread |  | | From | Keith Owens <> | Subject | Re: 2.6.16-rc6-mm2 | Date | Tue, 13 Jun 2006 22:41:33 +1000 |
| |
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/
|  |