lkml.org 
[lkml]   [2008]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfc] SLOB memory ordering issue


On Thu, 16 Oct 2008, Nick Piggin wrote:
>
> Who was it that said memory ordering was self-evident?

Nobody has _ever_ said that memory ordering is self-evident. Quite the
reverse.

What we've said is that it's not a ctor issue. This has nothing
what-so-ever to do with ctors, and everything to do with the fact that
lockless is hard.

And the general rule is: to find a page (or any other data structures) on
another CPU, you need to insert it into the right data structures. And
that insertion event needs to either be locked, or it needs to be ordered.

But notice that it's the _insertion_ event. Not the ctor. Not the
allocator. It's the person _doing_ the allocation that needs to order
things.

See?

And no, I didn't look at your exact case. But for pages in page tables,
we'd need to have the right smp_wmb() at the "set_pte[_at]()" stage,
either inside that macro or in the caller.

We used to only care about the page _contents_ (because the only unlocked
access was the one that was done by hardware), but now that we do unlocked
lookups in software too, we need to make sure the "struct page" itself is
also valid.

For non-page-table lookups (LRU, radix trees, etc etc), the rules are
different. Again, it's not an _allocator_ (or ctor) issue, it's about the
point where you insert the thing. If you insert the page using a lock, you
need not worry about memory ordering at all. And if you insert it using
RCU, you do.

This is *all* we have argued about. The argument is simple: this has
NOTHING to do with the allocator, and has NOTHING to do with constructors.

Linus


\
 
 \ /
  Last update: 2008-10-15 20:29    [W:1.618 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site