All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Andrew Morton <akpm@osdl.org>
Cc: "Ananiev, Leonid I" <leonid.i.ananiev@intel.com>,
	tim.c.chen@linux.intel.com, Jeremy Fitzhardinge <jeremy@goop.org>,
	herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix WARN_ON / WARN_ON_ONCE regression
Date: Sat, 07 Oct 2006 20:28:47 -0400	[thread overview]
Message-ID: <1160267327.2368.12.camel@localhost.localdomain> (raw)
In-Reply-To: <20061004102812.5f3b22d2.akpm@osdl.org>

On Wed, 2006-10-04 at 10:28 -0700, Andrew Morton wrote:
> On Wed, 4 Oct 2006 20:57:57 +0400
> "Ananiev, Leonid I" <leonid.i.ananiev@intel.com> wrote:
> 
> > >Guys.  Please.  Help us out here.  None of this makes sense, and it's
> > > possible that we have an underlying problem in there which we need to
> > know
> > > about.
> >  This is explantion:
> > 
> > The static variable __warn_once was "never" read (until there is no bug)
> > before patch "Let WARN_ON/WARN_ON_ONCE return the condition"
> > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
> > t;h=684f978347deb42d180373ac4c427f82ef963171
> >  in WARN_ON_ONCE's line 
> > - if (unlikely((condition) && __warn_once)) { \
> > because 'condition' is false. There was no cache miss as a result.
> > 
> > Cache miss for __warn_once is happened in new lines
> > + if (likely(__warn_once)) \
> > + if (WARN_ON(__ret_warn_once)) \
> > 
> 
> That's one cache miss.  One.  For the remainder of the benchmark,
> __warn_once is in cache and there are no more misses.  That's how caches
> work ;)
> 
> But it appears this isn't happening.  Why?

day-ja-vu!

Andrew, this discussion came up back when Ingo and Arjan introduced
WARN_ON_ONCE. Well, not exactly.  I'm sorry, but I missed what was wrong
with the current way of doing WARN_ON_ONCE?

Anyway, what's the advantage of testing a variable that is most likely
will be true, and that you will need to test the condition *anyway*.
Even if the __warn_once is in cache, it may be pushing something out of
a register, to read the variable and test it. And after all that we test
the condition too, with no savings.

Is this patch to get rid of the int ret=0?  Doesn't the compiler
optimize that out?

Here's my comment when I sent the patch to change the original:

  if (unlikely(__warn_once && (condition)))

to 

  if (unlikely((condition) && __warn_once)))

http://marc.theaimsgroup.com/?l=linux-kernel&m=114935833125957&w=2

That was different, since we were putting a likely condition in an
unlikely(). But I still don't see why we would ever want to test
__warn_once before the condition, since it doesn't save on anything and
just adds extra work.  I don't see the savings.

-- Steve


  reply	other threads:[~2006-10-08  0:29 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-04 16:57 [PATCH] Fix WARN_ON / WARN_ON_ONCE regression Ananiev, Leonid I
2006-10-04 17:28 ` Andrew Morton
2006-10-08  0:28   ` Steven Rostedt [this message]
2006-10-08  0:39     ` Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2006-10-10 21:05 Ananiev, Leonid I
2006-10-10 21:17 ` Steven Rostedt
2006-10-10 21:41   ` Roland Dreier
2006-10-10 22:59   ` Jeremy Fitzhardinge
2006-10-06  4:06 Ananiev, Leonid I
2006-10-04 21:55 Ananiev, Leonid I
2006-10-05 21:37 ` Andrew Morton
2006-10-05 21:43   ` Jeremy Fitzhardinge
2006-10-05 21:52     ` Andrew Morton
2006-10-05 22:02       ` Herbert Xu
2006-10-05 22:40         ` Jeremy Fitzhardinge
2006-10-05 21:51   ` Tim Chen
2006-10-06 16:11   ` Andrew James Wade
2006-10-03 23:04 Tim Chen
2006-10-03 23:19 ` Tim Chen
2006-10-04  0:06 ` Jeremy Fitzhardinge
2006-10-03 23:47   ` Tim Chen
2006-10-04  4:39     ` Jeremy Fitzhardinge
2006-10-04 13:21       ` Tim Chen
2006-10-04 16:30         ` Andrew Morton
2006-10-04 16:22           ` Tim Chen
2006-10-04 17:34             ` Andrew Morton
2006-10-04 20:43               ` Tim Chen
2006-10-10  1:09               ` Tim Chen
2006-10-10 13:04                 ` Steven Rostedt
2006-10-10 15:41                   ` Tim Chen
2006-10-10 20:03                   ` Jeremy Fitzhardinge
2006-10-04  0:07 ` Andrew Morton
2006-10-03 23:42   ` Tim Chen
2006-10-04  0:09   ` Tim Chen
2006-10-04  1:14     ` Andrew Morton
2006-10-04  1:47       ` Nick Piggin
2006-10-04  3:24       ` Andrew James Wade
2006-10-04  3:32         ` Andrew Morton
2006-10-04 16:47           ` Andrew James Wade
2006-10-04 22:06             ` Andrew Morton
2006-10-05  8:13               ` Andrew James Wade
2006-10-05  8:36                 ` Andrew Morton
2006-10-05 21:31                   ` Andrew James Wade
2006-10-05 21:01                     ` Tim Chen

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=1160267327.2368.12.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeremy@goop.org \
    --cc=leonid.i.ananiev@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.c.chen@linux.intel.com \
    /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.