Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12)

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Mar 16, 2015 at 03:43:56PM +0000, Mathieu Desnoyers wrote:
> > On which; I absolutely hate that rq->lock thing in there. What is
> > 'wrong' with doing a lockless compare there? Other than not actually
> > being able to deref rq->curr of course, but we need to fix that anyhow.
> 
> If we can make sure rq->curr deref could be done without holding the rq
> lock, then I think all we would need is to ensure that updates to rq->curr
> are surrounded by memory barriers. Therefore, we would have the following:
> 
> * When a thread is scheduled out, a memory barrier would be issued before
>   rq->curr is updated to the next thread task_struct.
> 
> * Before a thread is scheduled in, a memory barrier needs to be issued
>   after rq->curr is updated to the incoming thread.

I'm not entirely awake atm but I'm not seeing why it would need to be
that strict; I think the current single MB on task switch is sufficient
because if we're in the middle of schedule, userspace isn't actually
running.

So from the point of userspace the task switch is atomic. Therefore even
if we do not get a barrier before setting ->curr, the expedited thing
missing us doesn't matter as userspace cannot observe the difference.

> In order to be able to dereference rq->curr->mm without holding the
> rq->lock, do you envision we should protect task reclaim with RCU-sched ?

A recent discussion had Linus suggest SLAB_DESTROY_BY_RCU, although I
think Oleg did mention it would still be 'interesting'. I've not yet had
time to really think about that.