linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
	ak@linux.intel.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	peterz@infradead.org, linuxppc-dev@lists.ozlabs.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	namhyung@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Jiri Olsa <jolsa@redhat.com>, Pekka Enberg <penberg@iki.fi>
Subject: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
Date: Tue, 14 Apr 2015 10:55:41 +0200	[thread overview]
Message-ID: <20150414085541.GA30202@gmail.com> (raw)
In-Reply-To: <1428993665-2133-1-git-send-email-sukadev@linux.vnet.ibm.com>


* Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> wrote:

> This is another attempt to resurrect Andi Kleen's patchset so users
> can specify perf events by their event names rather than raw codes.
> 
> This is a rebase of Andi Kleen's patchset from Jul 30, 2014[1] to 4.0.
> (I fixed minor and not so minor conflicts).

So this series shows some progress, but instead of this limited 
checkout ability I'd still prefer it if 'perf download' downloaded the 
latest perf code itself and built it - it shouldn't be limited to just 
a small subset of the perf source code!

There's a few Git tricks we can use to make this palatable on most 
systems.

To save disk space and network bandwith this could be done using Git's 
'shallow clone' feature:

   git clone --depth 1 --bare

The initial checkout finishes in 1.5 minutes here, a continent away 
from korg. The resulting repository size is just 143MB.

The code could also check whether the user has already a ~/linux.git 
repository around, and use --reference ~/linux.git in that case. In 
such a case the cloning takes just 2 seconds.

To get the source code we could use Git's 'sparse checkout' feature:

   git config core.sparsecheckout true
   echo tools/ > .git/info/sparse-checkout
   git checkout tools/

Note that a sparse checkout build will need a few relatively simple 
other files as well, for the few files not in tools/ that the perf 
build needs - mostly include files.

I've attached below a working test script that will create a buildable 
tools/perf/ repository into ~/.perf/git/ of the latest tip/perf/core 
tree from kernel.org.

With ~/linux.git primed it takes under 10 seconds to execute. perf 
builds fine in the directory. The whole directory together with the 
Git repo is 53 MB - that could be shrunk some more if needed.

If there's no local Linux repository to fall back on to then the 
initial step takes 1.5 minutes (depending on network bandwidth) and 
another 140MB for the Git objects. It's a lot faster after that.

That way 'perf download' could also be renamed to 'perf upgrade'.

Building perf ought to be possible even on fairly limited development 
systems and our auto-detection and library install suggestions are 
pretty good.

And note that once we have that there's no reason to move the event 
descriptions into a separate file - it can be part of the perf binary 
itself.

> This patchset includes the perf-download tool that was dropped and 
> sets the default download location to the 
> (tools/perf/pmu-events/arch/... directory in Linus's tree.

So the way I think this would work best is for 'perf upgrade' to have 
different levels, similar to what the kernel has:

  perf upgrade devel               # pick files up from Arnaldo's korg tree
  perf upgrade next                # pick files up from tip.git on korg
  perf upgrade rc                  # pick files up from linus's Git tree
  perf upgrade stable              # pick files up the latest -stable version

'perf upgrade' would default to the most conservative, -stable 
variant, but of course users could pick whichever variant they prefer.

There's some limitations (such as if the build fails - but we want to 
fix such cases anyway), but note the fundamental power of this 
approach: 'perf upgrade' could turn any developer who has a perf 
binary into a perf tester and even into a contributor.

There's no need to even know Git or other development details - the 
latest code could be picked up and built.

'perf upgrade distro' could be offered as a way to downgrade to 
whatever previous (distro) perf version the user was using.

Likewise, later on this approach could be generalized into 
tools/build/ to enable self-hosting for other tools in tools/ as well, 
if they so desire.

Thanks,

	Ingo

============================>
#!/bin/bash
#
# Simple script that fetches the 'perf' utility from Linus's tree, builds and
# installs it, by creating a shallow clone and a sparse checkout for Linux's
# tools/ directory and related dependencies:
#

DIR=~/.perf/git

rm -rf $DIR
mkdir -p $DIR || { echo 'error: No write permissions in the current directory?'; exit -1; }
cd $DIR

#REPO=git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
#BRANCH=HEAD
REPO=git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
BRANCH=perf/core

REFERENCE="."
[ -d ~/linux/.git     ] && REFERENCE=~/linux/
[ -d ~/linux.git/.git ] && REFERENCE=~/linux.git/
[ -d ~/tip/.git       ] && REFERENCE=~/tip/
[ -d ~/tip.git/.git   ] && REFERENCE=~/tip.git/

git clone --reference $REFERENCE --depth 1 --bare $REPO --branch $BRANCH .git
git config --local core.bare false

git config --local core.sparseCheckout true
git remote remove origin
git remote add -f origin $REPO -t $BRANCH

(
  echo '/tools/*'
  echo '/lib/*'
  echo '/include/*'
  echo '/arch/x86/lib/*'
  echo '/arch/x86/include/*'
  echo 'Makefile'
  echo '/scripts/*'

) > .git/info/sparse-checkout

git checkout $BRANCH

make -C tools/perf/ install

  parent reply	other threads:[~2015-04-14  8:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14  6:40 [PATCH v9 00/11] Add support for JSON event files Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 01/11] perf, tools: Add jsmn `jasmine' JSON parser Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 02/11] perf, tools: Add support for text descriptions of events and alias add Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 03/11] perf, tools, list: Update perf list to output descriptions Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 04/11] perf, tools: Add support for reading JSON event files Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 05/11] perf, tools: Automatically look for event file name for cpu Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 06/11] powerpc/perf: Implement get_cpu_str() Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 07/11] perf, tools: Query terminal width and use in perf list Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 08/11] perf, tools: Add a new pmu interface to iterate over all events Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 09/11] perf, tools, test: Add test case for alias and JSON parsing Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 10/11] perf, tools: Add a --no-desc flag to perf list Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 11/11] perf-download: Download the events json file Sukadev Bhattiprolu
2015-04-14  8:55 ` Ingo Molnar [this message]
2015-04-14 11:21   ` 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.) Michael Ellerman
2015-04-14 12:58     ` Ingo Molnar
2015-04-14 18:03       ` Sukadev Bhattiprolu
2015-04-14 22:53       ` Michael Ellerman
2015-04-15  9:25         ` Ingo Molnar
2015-04-15 19:17           ` Andi Kleen
2015-04-15 20:50           ` Sukadev Bhattiprolu
2015-04-17 15:31             ` Jiri Olsa
2015-04-17 20:09               ` Andi Kleen
2015-04-18 13:05                 ` Jiri Olsa
2015-04-18 13:12             ` Jiri Olsa
2015-04-14 20:16   ` 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=20150414085541.GA30202@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=penberg@iki.fi \
    --cc=peterz@infradead.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=tglx@linutronix.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;
as well as URLs for NNTP newsgroup(s).