All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
	leonid.i.ananiev@intel.com
Subject: Re: [PATCH] Fix WARN_ON / WARN_ON_ONCE regression
Date: Wed, 04 Oct 2006 09:22:09 -0700	[thread overview]
Message-ID: <1159978929.8035.109.camel@localhost.localdomain> (raw)
In-Reply-To: <20061004093025.ab235eaa.akpm@osdl.org>

On Wed, 2006-10-04 at 09:30 -0700, Andrew Morton wrote:

> > I have measured the cache miss with tool.  So it is not just my theory.
> > 
> 
> And what did that tool tell you?

I am using emon.  Measuring a 20 second stretch of tbench run saw the L2
cache miss go from 14 million to 25 million on each of the cpu core.
> 
> Please don't just ignore my questions.  *why* are we getting a cache miss
> rate on that integer which is causing measurable performance changes?  If
> we're reading it that frequently then the variable should be in cache(!).
> 

The point is valid, __warn_once should be in cache, unless something
evicts it. What I have found so far is with patch by Andrew and Leonid
that avoid looking up the __warn_once integer, the cache miss rate is
reduced to the level before.  

> Again: do you know which callsite is causing the problem?  I assume one of
> the ones in softirq.c?  Do you know what the cache miss frequency is?  etc.
> 
Unfortunately emon does not directly give the callsite.  Oprofile data
shows a marked increase in time spent in do_softirq and local_bh_enable.
What I could do is to individually turn off WARN_ON_ONCE at these sites
and see if they are responsible for the cache miss.  Will let you know
what I found.

Oprofile data --
Before WARN_ON_ONCE patch:

117767 thread_return                           
106651 local_bh_enable                          
 83767 tcp_v4_rcv                                
 72266 copy_user_generic_unrolled               
 47136 do_softirq                              

 41100 tcp_recvmsg                               
 39394 tcp_sendmsg        
118383 thread_return                            
 88171 copy_user_generic                        
                           
..
  8281 local_bh_enable
  6790 do_softirq                                

After WARN_ON_ONCE patch:

117767 thread_return                           
106651 local_bh_enable                          
 83767 tcp_v4_rcv                                
 72266 copy_user_generic_unrolled               
 47136 do_softirq                              


Tim

  reply	other threads:[~2006-10-04 17:11 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 23:04 [PATCH] Fix WARN_ON / WARN_ON_ONCE regression 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2006-10-04 16:57 Ananiev, Leonid I
2006-10-04 17:28 ` Andrew Morton
2006-10-08  0:28   ` Steven Rostedt
2006-10-08  0:39     ` Jeremy Fitzhardinge
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-06  4:06 Ananiev, Leonid I
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

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=1159978929.8035.109.camel@localhost.localdomain \
    --to=tim.c.chen@linux.intel.com \
    --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 \
    /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.