All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat
Date: Wed, 1 Jul 2009 15:50:32 +0200	[thread overview]
Message-ID: <20090701135032.GA21069@elte.hu> (raw)
In-Reply-To: <20090701134501.GA5097@nowhere>


* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> On Wed, Jul 01, 2009 at 09:31:39AM +0200, Ingo Molnar wrote:
> > 
> > * Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:
> > 
> > > Hi,
> > > 
> > > I wrote a test patch which add information of counts processes 
> > > acquired how many spinlocks to schedstat. After applied this 
> > > patch, /proc/<PID>/sched will change like this,
> > > 
> > > init (1, #threads: 1)
> > > ---------------------------------------------------------
> > > se.exec_start                      :        482130.851458
> > > se.vruntime                        :         26883.107980
> > > se.sum_exec_runtime                :          2316.651816
> > > se.avg_overlap                     :             0.480053
> > > se.avg_wakeup                      :            14.999993
> > > ....
> > > se.nr_wakeups_passive              :                    1
> > > se.nr_wakeups_idle                 :                    0
> > > se.nr_acquired_spinlock            :                74483
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > Looks potentially useful - but it would be nice and go one step 
> > further and add lock acquire stats as a software-counter.
> > 
> > Perfcounters is a feature of the latest upstream kernel, there's a 
> > (still very small) Wiki page about it at:
> > 
> >    http://perf.wiki.kernel.org
> > 
> > With perfcounters we can instrument various software properties of 
> > the kernel as well, for example the number of page-faults in the 
> > system per second:
> > 
> >   $ perf stat -a -e page-faults sleep 1
> > 
> >   Performance counter stats for 'sleep 1':
> > 
> >           294387  page-faults             
> > 
> >      1.022318527  seconds time elapsed
> > 
> > Now, it would be nice to have a lock-acquire software-counter as 
> > well, which would output things like:
> > 
> >   $ perf stat -a -e lock-acquires sleep 1
> > 
> >   Performance counter stats for 'sleep 1':
> > 
> >           294387  lock-acquires
> > 
> >      1.022318527  seconds time elapsed
> > 
> > Furthermore, beyond plain counts, doing this would also allow the 
> > profiling of lock acquire places: perf record -e lock-acquires and 
> > perf report would work fine.
> > 
> > It is really easy to add a new sw counter, check how it is done for 
> > the pagefault counter(s), see the uses of PERF_COUNT_SW_PAGE_FAULTS 
> > in the following files:
> > 
> >   $ git grep -l PERF_COUNT_SW_PAGE_FAULTS
> > 
> >   arch/powerpc/mm/fault.c
> >   arch/x86/mm/fault.c
> >   include/linux/perf_counter.h
> >   kernel/perf_counter.c
> >   tools/perf/builtin-stat.c
> >   tools/perf/design.txt
> 
> 
> Indeed, the raw number of lock acquired may be useful for a perf 
> profiling especially in the case of profile comparison.
> 
> But IMHO, this information is too much orphan and lonesome. We 
> would gain a lot if this information is provided per lock. Another 
> useful info would be the rate of the time spent in a contended 
> state for a given lock.
> 
> Which makes me think it may be better to use the existing ftrace 
> lock events as softwares counters for that, which takes into 
> account the following events:
> 
> - lock_acquire
> - lock_release
> - lock_contended
> - lock_acquired
> 
> And these events are per lock.
> 
> Now the missing piece is the sampling count for events...

Yeah, this is an even better idea. It gets the acquire counts - and 
much more.

	Ingo

  reply	other threads:[~2009-07-01 13:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01  6:21 [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat Hitoshi Mitake
2009-07-01  7:31 ` Ingo Molnar
2009-07-01  8:21   ` Hitoshi Mitake
2009-07-01 13:45   ` Frederic Weisbecker
2009-07-01 13:50     ` Ingo Molnar [this message]
2009-07-01 14:17       ` mitake
2009-07-01  7:38 ` Andi Kleen
2009-07-01  8:42   ` Hitoshi Mitake
2009-07-01  9:07     ` Ingo Molnar
2009-07-01  9:42       ` Hitoshi Mitake
2009-07-01 11:06         ` Ingo Molnar
2009-07-01 12:53           ` Hitoshi Mitake
2009-07-01 15:44             ` Frederic Weisbecker
2009-07-06  5:20               ` mitake
2009-07-06  8:51                 ` Peter Zijlstra
2009-07-06 11:54                   ` Andi Kleen
2009-07-10 12:45                     ` mitake
2009-07-10 12:52                       ` Peter Zijlstra
2009-07-10 13:43                         ` Ingo Molnar
2009-07-10 13:46                           ` Frederic Weisbecker
2009-07-10 13:50                             ` Ingo Molnar
2009-07-10 13:56                               ` Peter Zijlstra
2009-07-12  7:23                         ` Hitoshi Mitake
2009-07-12 13:24                           ` Peter Zijlstra
2009-07-13  6:06                             ` Hitoshi Mitake
2009-07-13  8:51                               ` Ingo Molnar
2009-07-14  0:48                                 ` Hitoshi Mitake
2009-07-18 13:25                                   ` Ingo Molnar
2009-07-01 12:40       ` Andi Kleen
2009-07-01 13:50       ` [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat II Andi Kleen
2009-07-01  9:48     ` [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat Andi Kleen

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=20090701135032.GA21069@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mitake@dcl.info.waseda.ac.jp \
    --cc=paulus@samba.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.