Andi,
On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote:
> > + * pmu_desc: subdir containing the PMU register mapping information
> > +
> > + * reset_stats(W): echo 0 > reset_stats resets the statistics collected
> > by perfmon2.
> > + stats are available per-cpu in
Andi,
On Thu, May 31, 2007 at 07:28:28PM +0200, Andi Kleen wrote:
>
> > All the features currently supported are used by some tools and have
> > been requested by users.
>
> But are they actually all used? Is there something you would
> like to get rid of because it turned out more trouble than
> People will want perfom and oprofile in the same kernel, and we'd better
Yes.
> allow useage at the same time, so I'd be very much in favour of having
That would be nice, but is not imho critical.
> just one backend. Especially giving the huge amount of different
> performance counters we ha
On Thu, May 31, 2007 at 08:43:14PM +0200, Andi Kleen wrote:
> > I think the perform backend for oprofile is the right way to go.
> > I'd even go further and say we should merge the perfom backend with
> > oprofile as the only user first, because a) the current perfom user
> > interface is a complet
> I think the perform backend for oprofile is the right way to go.
> I'd even go further and say we should merge the perfom backend with
> oprofile as the only user first, because a) the current perfom user
> interface is a complete mess
Can you suggest concrete criticism/improvements/alternative
On Thu, May 31, 2007 at 07:28:28PM +0200, Andi Kleen wrote:
> I would prefer if oprofile would still work. It doesn't need to work
> in parallel but it should be possible to use it when perfmon
> is not active, but compiled in. That shouldn't be that difficult,
> should it?
I think the perform bac
On Thu, May 31, 2007 at 10:16:17AM -0700, Stephane Eranian wrote:
> Andi,
>
> On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote:
> > Stephane Eranian <[EMAIL PROTECTED]> writes:
> >
> > The interface looks very complicated. Is there anything
> > in there that you feel is not strictly ne
Andi,
On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote:
> Stephane Eranian <[EMAIL PROTECTED]> writes:
>
> The interface looks very complicated. Is there anything
> in there that you feel is not strictly needed and should be eliminated
> before merging? After merging it will be more di
Stephane Eranian <[EMAIL PROTECTED]> writes:
The interface looks very complicated. Is there anything
in there that you feel is not strictly needed and should be eliminated
before merging? After merging it will be more difficult.
> +/*
> + * number of elements for each type of bitvector
> + * all
9 matches
Mail list logo
