Messages in this thread | | | Subject | Re: [patch 2/3] scheduler: add full memory barriers upon task switch at runqueue lock/unlock | From | Steven Rostedt <> | Date | Mon, 01 Feb 2010 12:13:12 -0500 |
| |
On Mon, 2010-02-01 at 11:48 -0500, Mathieu Desnoyers wrote:
> What we have to be careful about here is that it's not enough to just > rely on switch_mm() containing a memory barrier. What we really need to > enforce is that switch_mm() issues memory barriers both _before_ and > _after_ mm_cpumask modification. The "after" part is usually dealt with > by the TLB context switch, but the "before" part usually isn't.
Then we add a smp_mb__before_clear_bit() in the switch_mm() on all archs that do not have clear_bit imply a smp_mb().
> > > > > Btw, one reason to strongly prefer "switch_mm()" over any random context > > switch is that at least it won't affect inter-thread (kernel or user-land) > > switching, including switching to/from the idle thread. > > > > So I'd be _much_ more open to a "let's guarantee that 'switch_mm()' always > > implies a memory barrier" model than to playing clever games with > > spinlocks. > > If we really want to make this patch less intrusive, we can consider > iterating on each online cpu in sys_membarrier() rather than on the > mm_cpumask. But it comes at the cost of useless cache-line bouncing on > large machines with few threads running in the process, as we would grab > the rq locks one by one for all cpus.
I still think modifying the switch_mm() is better than the full iteration.
-- Steve
| |