public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, sandmann@redhat.com, tglx@tglx.de,
	hpa@zytor.com
Subject: Re: [PATCH] x86: add the debugfs interface for the sysprof tool
Date: Sat, 23 Feb 2008 13:22:22 +0100	[thread overview]
Message-ID: <20080223122222.GA323@elte.hu> (raw)
In-Reply-To: <84144f020802230351o24b11282vbb1cecf518d91825@mail.gmail.com>


* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On Sat, Feb 23, 2008 at 10:11 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >  Seems a poor idea to me.  Sure, oprofile is "hard to set up", but not if
> >  your distributor already did it for you.
> 
> Have you tried sysprof? It's really nice to setup and use compared to 
> oprofile when profiling user-space.

yes, it's very nice and very usable - and that's all that matters 
really. It's almost a _duty_ of the mainstream kernel to include that 
trivial 200 lines of sysprof code, given how poor instrumentation 
support is on Linux.

As a comparison, here's a session of a newbie developer, meeting 
oprofile for the first time in his life (using a fresh package, 
oprofile-0.9.3-6.fc8):

  ---------------------->
  [ Newbie: WTF, no GUI tool? ]
  [ Narrator: we lose 90% of the developers at this point. ]
  [ Newbie is adventurous and has heard about opcontrol and tries it. ]
 
  # opcontrol

  [ Newbie sees tons of output. User scratches head. After looking 
    around, finds the following option listed:
    "-s/--start       start data collection". That must be it! ]

  # opcontrol -s
  No vmlinux file specified. You must specify the correct vmlinux file, e.g.
  opcontrol --vmlinux=/path/to/vmlinux
  If you do not have a vmlinux file, use
  opcontrol --no-vmlinux
  Enter opcontrol --help for full options

  [ Newbie: WTF? Doesnt oprofile think that what I want to do is to 
    profile ... the currently running kernel, wherever a kernel is 
    and whatever a vmlinux might be?? ]

  [ Narrator: At this point oprofile has confused about 99% of all 
    user-space developers who have no freaking idea about what a vmlinux 
    is. ]

  [ Newbie user figures that --no-vmlinux might be the right option: ]

  # opcontrol -s --no-vmlinux
  Option "--setup" not valid with "-s".

  [ Newbie: WTF? what not valid? Why should i care? Damnit, i only want 
    to profile stuff!!! ]

  [ The newbie user eventually finds out that opcontrol help text is 
    buggy and that -s does not mean --start, but --setup. ]

  [ Narrator: we now have lost 99.99% of the first-time users. ]

  [ Newbie, armed with this nontrivial piece of information: ]

  # opcontrol --start --no-vmlinux
 
  Using default event: CPU_CLK_UNHALTED:100000:0:1:1
  Using 2.6+ OProfile kernel interface.
  Using log file /var/lib/oprofile/samples/oprofiled.log
  Daemon started.
  Profiler running.

  [ Newbie: wow, it's working! Lets start an infinite loop and lets try 
    this opreport thing: ]

  # opreport

   CPU_CLK_UNHALT...|
     samples|      %|
   ------------------
       160405 82.9309 loop

  [ Newbie: hm, i see where the overhead is - but which function is 
    calling it? ]

  [ Newbie user wants to restart profiling and figures that
    opcontrol --reset will do that: ]

  # opcontrol --reset
  Signalling daemon... done

  [ GREAT! It even said "done". Now lets see our new profile: ]

  # opreport
  opreport error: No sample file found: try running opcontrol --dump
  or specify a session containing sample files

  [ Newbie: WTF???? ]

  [ Narrator: we've now lost 99.99999% of the testers at this point. The 
    reamining 10 kernel developers still using oprofile have written up 
    all the commands to the back of their keyboards, for easy reference. ]
  <----------------------

We should hang our collective heads in shame. Oprofile is an utter joke 
in terms of usability. It had 5-10 years to get its stuff together and 
didnt.

200 lines of totally isolated sysprof code is the least thing we can do 
which we _must do_ to help our users.

	Ingo

  reply	other threads:[~2008-02-23 12:22 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-19 20:37 [PATCH] x86: add the debugfs interface for the sysprof tool Arjan van de Ven
2008-02-20  9:10 ` Ingo Molnar
2008-02-26  4:13   ` Anton Blanchard
2008-02-26  8:57     ` Ingo Molnar
2008-02-20 18:16 ` Peter Zijlstra
2008-02-20 18:39   ` Arjan van de Ven
2008-02-20 18:53     ` Peter Zijlstra
2008-02-20 18:58       ` Peter Zijlstra
2008-02-26  5:03         ` Anton Blanchard
2008-02-20 19:26       ` Arjan van de Ven
2008-02-20 20:58         ` Peter Zijlstra
2008-02-20 21:07           ` Arjan van de Ven
2008-02-20 21:44             ` Peter Zijlstra
2008-02-20 22:36               ` Arjan van de Ven
2008-02-23  8:11 ` Andrew Morton
2008-02-23 11:37   ` Ingo Molnar
2008-02-23 13:53     ` John Levon
2008-02-23 15:50       ` Ingo Molnar
2008-02-23 20:15       ` Soeren Sandmann
2008-02-23 20:42         ` Andrew Morton
2008-02-26  5:13         ` Anton Blanchard
2008-02-26  9:02           ` Ingo Molnar
2008-02-26 17:29             ` Andrew Morton
2008-02-27 14:05             ` Anton Blanchard
2008-02-24 13:10       ` Theodore Tso
2008-02-24 13:44         ` Ingo Molnar
2008-02-24 14:33           ` Ingo Molnar
2008-02-24 16:32         ` John Levon
2008-02-24 18:19           ` Theodore Tso
2008-02-23 18:40     ` Andrew Morton
2008-02-23 11:51   ` Pekka Enberg
2008-02-23 12:22     ` Ingo Molnar [this message]
2008-02-23 12:29       ` Pekka Enberg
2008-02-23 18:46     ` Andrew Morton
2008-02-24  2:49       ` Pekka Enberg
2008-02-24  3:12         ` Nicholas Miell
2008-02-26  6:27           ` Pekka Enberg
2008-02-26  6:48             ` Pekka Enberg
2008-02-26  8:55               ` Ingo Molnar
2008-02-23 14:54   ` Pekka Enberg
2008-02-23 19:01     ` Andrew Morton

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=20080223122222.GA323@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=sandmann@redhat.com \
    --cc=tglx@tglx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox