Prev: xfs: add a shrinker to background inode reclaim
Next: ACPI Errors on Acer Aspire One
From: Peter Zijlstra on 11 May 2010 10:50
On Tue, 2010-05-11 at 16:04 +0200, Stephane Eranian wrote:
> Hi,
>
>
> I am confused by the inheritance cmd line option of perf record:
>
> $ perf record -h
> usage: perf record [<options>] [<command>]
> or: perf record [<options>] -- <command> [<options>]
>
> -e, --event <event> event selector. use 'perf list' to list
> available events
> --filter <filter>
> event filter
> -p, --pid <n> record events on existing process id
> -t, --tid <n> record events on existing thread id
> -r, --realtime <n> collect data with this RT SCHED_FIFO priority
> -R, --raw-samples collect raw sample records from all opened counters
> -a, --all-cpus system-wide collection from all CPUs
> -A, --append append to the output file to do incremental profiling
> -C, --profile_cpu <n>
> CPU to profile on
> -f, --force overwrite existing data file (deprecated)
> -c, --count event period to sample
> -o, --output <file> output file name
> -i, --inherit child tasks inherit counters
>
> This leads to believe that by default inheritance in children is off.
>
> However, builtin-record.c says:
>
> static bool inherit = true;
>
> If that's the case, what's the point of the -i option?

Right, I think we should invert that, does --no-inherit work?

> Another side effect of inheritance is that in per-thread mode,
> perf creates as many "sessions" as you have CPUs. So
> on a 16-way processor, sampling on cycles, perf creates
> 16 events and 16 x 2-page sampling buffers. That's a lot of
> resources consumed if I am just interested in monitoring
> a single-threaded workload.

Right, but I think the default of inherit is right, and once you do that
you basically have to do the per-task-per-cpu thing, otherwise your
fancy 16-way will start spending most of its time in cacheline bounces.

That said, !inherit wouldn't need that, so a patch doing that would be
nice.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 11 May 2010 11:10
Em Tue, May 11, 2010 at 04:04:17PM +0200, Stephane Eranian escreveu:
> I am confused by the inheritance cmd line option of perf record:

> usage: perf record [<options>] [<command>]
> or: perf record [<options>] -- <command> [<options>]
> -p, --pid <n> record events on existing process id
> -t, --tid <n> record events on existing thread id
> -a, --all-cpus system-wide collection from all CPUs
> -C, --profile_cpu <n> CPU to profile on
> -i, --inherit child tasks inherit counters

> This leads to believe that by default inheritance in children is off.

> However, builtin-record.c says:
> static bool inherit = true;

> If that's the case, what's the point of the -i option?

Humm, since for -C and -a using -i doesn't make sense, I guess it should
be off by default and only be auto-activated if we don't specify any
option, i.e. when using it like:

perf record ./hackbench

What do you think?

> Another side effect of inheritance is that in per-thread mode, perf
> creates as many "sessions" as you have CPUs. So on a 16-way processor,
> sampling on cycles, perf creates 16 events and 16 x 2-page sampling
> buffers. That's a lot of resources consumed if I am just interested in
> monitoring a single-threaded workload.

> Am I missing something here?

I don't think so, but maybe I'm missing too :-)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 11 May 2010 11:20
On Tue, 2010-05-11 at 12:00 -0300, Arnaldo Carvalho de Melo wrote:
>
> Humm, since for -C and -a using -i doesn't make sense, I guess it should
> be off by default and only be auto-activated if we don't specify any
> option, i.e. when using it like:
>
> perf record ./hackbench
>
> What do you think?

-ENOPARSE

-a/-C usage creates per-cpu counters and will thus ignore any and all
perf_event_attr::inherit state.

Your above suggestion would still have inherit enabled by default, and
would thus not change anything.

The thing is that perf-record defaults to inherited per-task-per-cpu
counters, which, I think, is a reasonable default, just sub-optimal for
single threaded/!forking subjects.

So what would make sense is for -i to mean --no-inherit, and for !
inherit create a per-task counter instead of a per-task-per-cpu counter.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 11 May 2010 11:20
On Tue, May 11, 2010 at 5:13 PM, Peter Zijlstra <peterz(a)infradead.org> wrote:
> On Tue, 2010-05-11 at 12:00 -0300, Arnaldo Carvalho de Melo wrote:
>>
>> Humm, since for -C and -a using -i doesn't make sense, I guess it should
>> be off by default and only be auto-activated if we don't specify any
>> option, i.e. when using it like:
>>
>> perf record ./hackbench
>>
>> What do you think?
>
> -ENOPARSE
>
> -a/-C usage creates per-cpu counters and will thus ignore any and all
> perf_event_attr::inherit state.
>
> Your above suggestion would still have inherit enabled by default, and
> would thus not change anything.
>
> The thing is that perf-record defaults to inherited per-task-per-cpu
> counters, which, I think, is a reasonable default, just sub-optimal for
> single threaded/!forking subjects.
>
> So what would make sense is for -i to mean --no-inherit, and for !
> inherit create a per-task counter instead of a per-task-per-cpu counter.
>

If inherit is the preferred default, then yes, the solution is to revert
the meaning of -i. You'd have to be consistent across all commands
using -i for inherit such as perf stat.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 11 May 2010 12:00
Em Tue, May 11, 2010 at 05:13:20PM +0200, Peter Zijlstra escreveu:
> On Tue, 2010-05-11 at 12:00 -0300, Arnaldo Carvalho de Melo wrote:
> > Humm, since for -C and -a using -i doesn't make sense, I guess it should
> > be off by default and only be auto-activated if we don't specify any
> > option, i.e. when using it like:

> > perf record ./hackbench

> -ENOPARSE

> -a/-C usage creates per-cpu counters and will thus ignore any and all
> perf_event_attr::inherit state.

What I tried to say was that if one does:

perf record -t 1234

then inherit would be off, or if:

perf record -p 5678

it would also be off.

but when just pass some program to run, like in:

perf record make -j allmodconfig

we would then assume that the user is interested in everything that the
program perf is starting does, i.e. the user is interested in the whole
workload started from perf, thus we would auto-enable -i.

> Your above suggestion would still have inherit enabled by default, and
> would thus not change anything.

Nope, see above.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3
Prev: xfs: add a shrinker to background inode reclaim
Next: ACPI Errors on Acer Aspire One