All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH for-3.3] mempool: clean up and document synchronization and memory barrier usage
Date: Wed, 21 Dec 2011 10:52:37 -0800	[thread overview]
Message-ID: <20111221185237.GI9213@google.com> (raw)
In-Reply-To: <20111221174057.GA32347@redhat.com>

Hello,

On Wed, Dec 21, 2011 at 06:40:58PM +0100, Oleg Nesterov wrote:
> > The first paragraph is saying that at that point full barrier (for
> > both stores and loads) is necessary at that point and the second
> > paragraph is a bit confusing but the last sentence seems to say that
> > only loads after the unlock can creep above unlock,
> 
> Probably, this is because the comment tries to explain the possible
> reordering with the subsequent "if (condition)" check, so it only
> mentions loads.

Ah, I see.

> > Anyways, yeah, you're right.  We need a smp_wmb() before returning but
> > I think the comment on top of prepare_to_wait() is misleading.
> 
> Hmm. I am not sure I understand... Although almost everything written
> in English looks misleading to me ;)

Amen. :) I missed the context there, so please forget about it.

> > Great, thanks.  I'll wait a bit for futher comments and repost w/
> > smp_wmb() added.
> 
> Well. This is almost off-topic, but perhaps we can add
> smp_mb__after_unlock() ? We already have smp_mb__after_lock.
> Afaics prepare_to_wait() could use it.
> 
> I am not talking about perfomance issues, just I think the code
> will be more understandable.

Hmmm... maybe.  I really don't know.

Thanks.

-- 
tejun

  reply	other threads:[~2011-12-21 18:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-20 22:18 [PATCH for-3.3] mempool: clean up and document synchronization and memory barrier usage Tejun Heo
2011-12-21 14:55 ` Oleg Nesterov
2011-12-21 14:57   ` Oleg Nesterov
2011-12-21 16:37   ` Tejun Heo
2011-12-21 16:44     ` Tejun Heo
2011-12-21 17:40     ` Oleg Nesterov
2011-12-21 18:52       ` Tejun Heo [this message]
2011-12-21 15:12 ` mempool && io_schedule_timeout() Oleg Nesterov
2011-12-21 15:34   ` Tejun Heo
2011-12-21 19:08 ` [PATCH for-3.3 UPDATED] mempool: fix and document synchronization and memory barrier usage Tejun Heo

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=20111221185237.GI9213@google.com \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --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.