From: Matt Mackall <mpm@selenic.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc] SLOB memory ordering issue
Date: Wed, 15 Oct 2008 13:19:13 -0500 [thread overview]
Message-ID: <1224094753.3316.266.camel@calx> (raw)
In-Reply-To: <200810160512.28443.nickpiggin@yahoo.com.au>
On Thu, 2008-10-16 at 05:12 +1100, Nick Piggin wrote:
> On Thursday 16 October 2008 05:03, Linus Torvalds wrote:
> > On Thu, 16 Oct 2008, Nick Piggin wrote:
> > > What do you mean by the allocation is stable?
> >
> > "all writes done to it before it's exposed".
> >
> > > 2. I think it could be easy to assume that the allocated object that was
> > > initialised with a ctor for us already will have its initializing stores
> > > ordered when we get it from slab.
> >
> > You make tons of assumptions.
> >
> > You assume that
> > (a) unlocked accesses are the normal case and should be something the
> > allocator should prioritize/care about.
> > (b) that if you have a ctor, it's the only thing the allocator will do.
>
> Yes, as I said, I do not want to add a branch and/or barrier to the
> allocator for this. I just want to flag the issue and discuss whether
> there is anything that can be done about it.
Well the alternative is to have someone really smart investigate all the
lockless users of ctors and add appropriate barriers. I suspect that's a
fairly small set and that you're already familiar with most of them.
But yes, I think you may be on to a real problem. It might also be worth
devoting a few neurons to thinking about zeroed allocations.
--
Mathematics is the supreme nostalgia of our time.
WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc] SLOB memory ordering issue
Date: Wed, 15 Oct 2008 13:19:13 -0500 [thread overview]
Message-ID: <1224094753.3316.266.camel@calx> (raw)
In-Reply-To: <200810160512.28443.nickpiggin@yahoo.com.au>
On Thu, 2008-10-16 at 05:12 +1100, Nick Piggin wrote:
> On Thursday 16 October 2008 05:03, Linus Torvalds wrote:
> > On Thu, 16 Oct 2008, Nick Piggin wrote:
> > > What do you mean by the allocation is stable?
> >
> > "all writes done to it before it's exposed".
> >
> > > 2. I think it could be easy to assume that the allocated object that was
> > > initialised with a ctor for us already will have its initializing stores
> > > ordered when we get it from slab.
> >
> > You make tons of assumptions.
> >
> > You assume that
> > (a) unlocked accesses are the normal case and should be something the
> > allocator should prioritize/care about.
> > (b) that if you have a ctor, it's the only thing the allocator will do.
>
> Yes, as I said, I do not want to add a branch and/or barrier to the
> allocator for this. I just want to flag the issue and discuss whether
> there is anything that can be done about it.
Well the alternative is to have someone really smart investigate all the
lockless users of ctors and add appropriate barriers. I suspect that's a
fairly small set and that you're already familiar with most of them.
But yes, I think you may be on to a real problem. It might also be worth
devoting a few neurons to thinking about zeroed allocations.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-10-15 18:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-15 16:34 [rfc] SLOB memory ordering issue Nick Piggin
2008-10-15 16:34 ` Nick Piggin
2008-10-15 16:46 ` Nick Piggin
2008-10-15 16:46 ` Nick Piggin
2008-10-15 16:54 ` Matt Mackall
2008-10-15 16:54 ` Matt Mackall
2008-10-15 17:10 ` Nick Piggin
2008-10-15 17:10 ` Nick Piggin
2008-10-15 17:33 ` Linus Torvalds
2008-10-15 17:33 ` Linus Torvalds
2008-10-15 17:36 ` Linus Torvalds
2008-10-15 17:36 ` Linus Torvalds
2008-10-15 17:58 ` Matt Mackall
2008-10-15 17:58 ` Matt Mackall
2008-10-15 17:45 ` Nick Piggin
2008-10-15 17:45 ` Nick Piggin
2008-10-15 18:03 ` Linus Torvalds
2008-10-15 18:03 ` Linus Torvalds
2008-10-15 18:12 ` Nick Piggin
2008-10-15 18:12 ` Nick Piggin
2008-10-15 18:19 ` Matt Mackall [this message]
2008-10-15 18:19 ` Matt Mackall
2008-10-15 18:35 ` Nick Piggin
2008-10-15 18:35 ` Nick Piggin
2008-10-15 18:43 ` Linus Torvalds
2008-10-15 18:43 ` Linus Torvalds
2008-10-15 19:19 ` Nick Piggin
2008-10-15 19:19 ` Nick Piggin
2008-10-15 19:47 ` Linus Torvalds
2008-10-15 19:47 ` Linus Torvalds
2008-10-15 18:29 ` Linus Torvalds
2008-10-15 18:29 ` Linus Torvalds
2008-10-15 18:06 ` Nick Piggin
2008-10-15 18:06 ` Nick Piggin
2008-10-15 18:26 ` Linus Torvalds
2008-10-15 18:26 ` Linus Torvalds
2008-10-15 18:50 ` Nick Piggin
2008-10-15 18:50 ` Nick Piggin
2008-10-17 20:29 ` Linus Torvalds
2008-10-17 20:29 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1224094753.3316.266.camel@calx \
--to=mpm@selenic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.