From: Stephane Eranian <eranian@hpl.hp.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/22] 2.6.22-rc3 perfmon2 : generic kernel modifications
Date: Thu, 7 Jun 2007 01:18:32 -0700 [thread overview]
Message-ID: <20070607081832.GD14081@frankl.hpl.hp.com> (raw)
In-Reply-To: <alpine.DEB.0.99.0706040810500.11881@chino.kir.corp.google.com>
David,
On Mon, Jun 04, 2007 at 08:13:41AM -0700, David Rientjes wrote:
> On Tue, 29 May 2007, Stephane Eranian wrote:
>
> > Only in linux-2.6.22/Documentation: perfmon2.txt
>
> You need to send -N to diff(1) so this and perfmon.h, perfmon_dfl_smpl.h,
> perfmon_fmt.h, and perfmon_pmu.h will be included in the patch. A
> patchset should compile and work correctly at any time when each patch is
> applied consecutively. Providing perfmon.h, for example, in patch 13
> doesn't allow individual testing of all prior patches.
>
The 'patch set' I publish on LKML is artificially created from the perfmon
patch tarball. As such, it does not have the property yuo are talking about here.
There is no independence of each patch. They are all more or less nedeed to get
the kernel to compile.
> > +++ linux-2.6.22/drivers/oprofile/oprofile_files.c 2007-05-29 03:24:14.000000000 -0700
> > +
> > +static ssize_t implementation(struct file * file, char __user * buf, size_t count, loff_t * offset)
> > +{
> > + return oprofilefs_str_to_user(oprofile_ops.implementation, buf, count, offset);
> > +}
> > +
> > +
> > +static struct file_operations implementation_fops = {
> > + .read = implementation,
> > +};
> > +
> > void oprofile_create_files(struct super_block * sb, struct dentry * root)
> > {
> > oprofilefs_create_file(sb, root, "enable", &enable_fops);
> > @@ -127,6 +137,7 @@ void oprofile_create_files(struct super_
> > oprofilefs_create_ulong(sb, root, "buffer_watershed", &fs_buffer_watershed);
> > oprofilefs_create_ulong(sb, root, "cpu_buffer_size", &fs_cpu_buffer_size);
> > oprofilefs_create_file(sb, root, "cpu_type", &cpu_type_fops);
> > + oprofilefs_create_file(sb, root, "implementation", &implementation_fops);
> > oprofilefs_create_file(sb, root, "backtrace_depth", &depth_fops);
> > oprofilefs_create_file(sb, root, "pointer_size", &pointer_size_fops);
> > oprofile_create_stats_files(sb, root);
>
> The commentary for how to interpret this new file is lacking; it appears
> as though it will return "timer", "oprofile", or "nmi_timer" for existing
> i386 subsystems and "perfmon2" with this addition. This should be
> documented.
>
> It isn't set generically in oprofile_arch_init() for other architectures.
This modification of oprofile was one to allow the user level oprofile daemon
to determine which kernel "implementation" of oprofile it is running on. This
way tool could transparently run on existing Oprofile and also on systems
with both perfmon and Oprofile.
Andi suggested that during a transition period, we let Oprofile and perfmon
co-exist as opposed to moving Oprofile on top of perfmon right away. I think this
is a good suggestion. As a consequence, I will remove this Oprofile extension.
> > diff --exclude=.git -urp --exclude-from=/tmp/excl315935 linux-2.6.22.base/kernel/sched.c linux-2.6.22/kernel/sched.c
> > --- linux-2.6.22.base/kernel/sched.c 2007-05-29 03:17:57.000000000 -0700
> > +++ linux-2.6.22/kernel/sched.c 2007-05-29 03:24:14.000000000 -0700
> > @@ -53,6 +53,7 @@
> > #include <linux/kprobes.h>
> > #include <linux/delayacct.h>
> > #include <linux/reciprocal_div.h>
> > +#include <linux/perfmon.h>
>
> perfmon.h isn't included in this patch so the inclusion of it here is a
> mystery but I suspect it's for pfm_ctxsw() later.
>
Yes most likely.
thanks for your feedback.
--
-Stephane
prev parent reply other threads:[~2007-06-07 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 13:48 Stephane Eranian
2007-05-29 14:46 ` Stephen Rothwell
2007-05-30 11:34 ` Robin Holt
2007-05-30 13:42 ` Stephen Rothwell
2007-05-30 13:56 ` Stephane Eranian
2007-06-04 15:13 ` David Rientjes
2007-06-07 8:18 ` Stephane Eranian [this message]
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=20070607081832.GD14081@frankl.hpl.hp.com \
--to=eranian@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®