Re: [RFC PATCH] introduce sys_membarrier(): process-wide memorybarrier (v3a)

From: Mathieu Desnoyers
Date: Mon Jan 11 2010 - 17:09:56 EST

* Peter Zijlstra (peterz@xxxxxxxxxxxxx) wrote:
> On Mon, 2010-01-11 at 15:52 -0500, Mathieu Desnoyers wrote:
> >
> > So the clear bit can occur far, far away in the future, we don't care.
> > We'll just send extra IPIs when unneeded in this time-frame.
> I think we should try harder not to disturb CPUs, particularly in the
> face of RT tasks and DoS scenarios. Therefore I don't think we should
> just wildly send to mm_cpumask(), but verify (although speculatively)
> that the remote tasks' mm matches ours.

Well, my point of view is that if IPI TLB shootdown does not care about
disturbing CPUs running other processes in the time window of the lazy
removal, why should we ? We're adding an overhead very close to that of
an unrequired IPI shootdown which returns immediately without doing

The tradeoff here seems to be:
- more overhead within switch_mm() for more precise mm_cpumask.
- lazy removal of the cpumask, which implies that some processors
running a different process can receive the IPI for nothing.

I really doubt we could create an IPI DoS based on such a small
time window.



Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at