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:
>
> I guess I wouldn't bother with your kernel. I was being hypothetical.
> Can you _prove_ no code has a bug due specifically to this issue?

Nick, nobody can prove anything but the most trivial programs.

> Did you read the anon_vma example? It's broken if it assumes the objects
> coming out of its slab are always "stable".

So why do you blame SLOB/SLAB?

This is my whole and only point - you're pointing at all the wrong things,
and then I get upset when I point out to you - over and over again - that
you point to the wrong thing, and you just keep on (once more) pointing to
it.

Can you see my frustration? You keep on claiming this is somehow an
issue of the slab allocator, and seem to refuse to just read what I write.

But let me try it again:

- The object you get from kmalloc (or *any* allocator) is a per-CPU
object. It's your _local_ memory area. And it has to be that way,
because no allocator can ever know the difference between objects that
are going to have global visibility and objects that don't. So the
allocator has to basically assume the cheap case.

- Yes, we could add a "smp_wmb()" at the end of all allocators, but that
would be a pointless no-op on architectures where it doesn't matter,
and it would be potentially expensive on architectures where it _does_
matter. In other words, in neither case is it the right thing to do.

- Most allocations by _far_ (at least in the static sense of "there's a
lot of kmalloc/kmem_cache_alloc's in the kernel") are going to be used
for things that are either thread-local (think temporary data
structures like "__getname()" for path allocators) or are going to be
used with proper locking.

NONE OF THOSE CASES WANT THE OVERHEAD! And they are the *common* ones.

- constructiors really have absolutely nothing to do with anything. What
about kzalloc()? That's an implicit "constructor" too. Do you want the
smp_wmb() there for that too? Do you realize that 99.9% of all such
users will fill in a few bytes/fields in _addition_ to clearing the
structure they just allocated? You do realize that almost nobody wants
a really empty data structure? You _do_ realize that the "smp_wmb()" in
the allocator IS TOTALLY USELESS if the code that did the allocation
then updates a few other fields too?

ADDING the smp_wmb() at an allocation point WOULD BE ACTIVELY
MISLEADING. Anybody who thinks that it helps is just fooling himself.

We're *much* better off just telling everybody that if they think they
can do lockless data structures, they have to do the memory ordering at
the _insertion_ point, and stop believing in fairies and wizards and in
allocators doing it for them!

- For _all_ of these reasons, any time you say that this is an allocator
issue, or a constructor issue, I don't need to even bother reading any
more. Because you've just shown yourself to not read what I wrote, nor
understand the issue.

So if you want to have a constructive discussion, you need to

- *read* what I wrote. UNDERSTAND that memory ordering is a non-issue
when there is locking involved, and that locking is still the default
approach for any normal data structure.

- *stop* talking about "constructors" and "SLOB allocators". Because as
long as you do, you're not making sense.

and if you can do that, I can treat you like you're worth talking to. But
as long as you cannot accept that, what's the point?

Linus


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