On 12/06/2015 5:21 p.m., David Ahern wrote:
On 6/12/15 4:34 AM, Adrian Hunter wrote:
On 12/06/15 03:47, David Ahern wrote:
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier
On 6/12/15 7:28 AM, Pawel Moll wrote:
Thanks, that's clear then. There will just need to be a flag to indicate
whether it is scheduling in or out.
Just a thought: wouldn't it be good to know what CPU have we been
scheduled from/to? This kind of information would be especially valuable
in
On 6/12/15 5:12 AM, Adrian Hunter wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On 6/12/15 4:34 AM, Adrian Hunter wrote:
On 12/06/15 03:47, David Ahern wrote:
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like
On Fri, 2015-06-12 at 14:28 +0100, Pawel Moll wrote:
> On Fri, 2015-06-12 at 14:15 +0100, Adrian Hunter wrote:
> > all 3 are already part of sample_id.
> > >>>
> > >>> You have to decide whether you expect to be able to use an event without
> > >>> sample_id. MMAP and MMAP2 both have pid, tid
On Fri, 2015-06-12 at 14:15 +0100, Adrian Hunter wrote:
> all 3 are already part of sample_id.
> >>>
> >>> You have to decide whether you expect to be able to use an event without
> >>> sample_id. MMAP and MMAP2 both have pid, tid which are in sample_id, LOST
> >>> has id, EXIT and FORK have
On 12/06/15 15:36, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 12, 2015 at 02:09:38PM +0200, Peter Zijlstra escreveu:
>> On Fri, Jun 12, 2015 at 02:12:11PM +0300, Adrian Hunter wrote:
>>> On 11/06/15 17:15, Peter Zijlstra wrote:
>>
Right, so the one wee problem I have is that this only
Em Fri, Jun 12, 2015 at 02:09:38PM +0200, Peter Zijlstra escreveu:
> On Fri, Jun 12, 2015 at 02:12:11PM +0300, Adrian Hunter wrote:
> > On 11/06/15 17:15, Peter Zijlstra wrote:
>
> > > Right, so the one wee problem I have is that this only provides sched_in
> > > data, I imagine people might be
On Fri, Jun 12, 2015 at 02:12:11PM +0300, Adrian Hunter wrote:
> On 11/06/15 17:15, Peter Zijlstra wrote:
> > Right, so the one wee problem I have is that this only provides sched_in
> > data, I imagine people might be interested in sched_out as well.
>
> That is not a problem although it would
On 11/06/15 17:15, Peter Zijlstra wrote:
> On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
>> Tracepoints are no good at all for non-privileged users
>> because they need either CAP_SYS_ADMIN or
>> /proc/sys/kernel/perf_event_paranoid <= -1.
>>
>> On the other hand, kernel software
On 12/06/15 03:47, David Ahern wrote:
> On 6/11/15 8:15 AM, Peter Zijlstra wrote:
>>> This new PERF_RECORD_SWITCH event does not have those problems
>>> and it also has a couple of other small advantages. It is
>>> easier to use because it is an auxiliary event (like mmap,
>>> comm and task
On 11/06/15 17:15, Peter Zijlstra wrote:
On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
Tracepoints are no good at all for non-privileged users
because they need either CAP_SYS_ADMIN or
/proc/sys/kernel/perf_event_paranoid = -1.
On the other hand, kernel software events need
Em Fri, Jun 12, 2015 at 02:09:38PM +0200, Peter Zijlstra escreveu:
On Fri, Jun 12, 2015 at 02:12:11PM +0300, Adrian Hunter wrote:
On 11/06/15 17:15, Peter Zijlstra wrote:
Right, so the one wee problem I have is that this only provides sched_in
data, I imagine people might be interested
On 12/06/15 03:47, David Ahern wrote:
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can
On Fri, Jun 12, 2015 at 02:12:11PM +0300, Adrian Hunter wrote:
On 11/06/15 17:15, Peter Zijlstra wrote:
Right, so the one wee problem I have is that this only provides sched_in
data, I imagine people might be interested in sched_out as well.
That is not a problem although it would be
On 12/06/15 15:36, Arnaldo Carvalho de Melo wrote:
Em Fri, Jun 12, 2015 at 02:09:38PM +0200, Peter Zijlstra escreveu:
On Fri, Jun 12, 2015 at 02:12:11PM +0300, Adrian Hunter wrote:
On 11/06/15 17:15, Peter Zijlstra wrote:
Right, so the one wee problem I have is that this only provides
On Fri, 2015-06-12 at 14:15 +0100, Adrian Hunter wrote:
all 3 are already part of sample_id.
You have to decide whether you expect to be able to use an event without
sample_id. MMAP and MMAP2 both have pid, tid which are in sample_id, LOST
has id, EXIT and FORK have time, all of the
On 12/06/2015 5:21 p.m., David Ahern wrote:
On 6/12/15 4:34 AM, Adrian Hunter wrote:
On 12/06/15 03:47, David Ahern wrote:
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier
On 6/12/15 7:28 AM, Pawel Moll wrote:
Thanks, that's clear then. There will just need to be a flag to indicate
whether it is scheduling in or out.
Just a thought: wouldn't it be good to know what CPU have we been
scheduled from/to? This kind of information would be especially valuable
in
On Fri, 2015-06-12 at 14:28 +0100, Pawel Moll wrote:
On Fri, 2015-06-12 at 14:15 +0100, Adrian Hunter wrote:
all 3 are already part of sample_id.
You have to decide whether you expect to be able to use an event without
sample_id. MMAP and MMAP2 both have pid, tid which are in
On 6/12/15 4:34 AM, Adrian Hunter wrote:
On 12/06/15 03:47, David Ahern wrote:
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like
On 6/12/15 5:12 AM, Adrian Hunter wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On Thu, Jun 11, 2015 at 09:34:30AM -0700, Andi Kleen wrote:
> On Thu, Jun 11, 2015 at 04:15:48PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
> > > Tracepoints are no good at all for non-privileged users
> > > because they need either
On Thu, Jun 11, 2015 at 04:15:48PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
> > Tracepoints are no good at all for non-privileged users
> > because they need either CAP_SYS_ADMIN or
> > /proc/sys/kernel/perf_event_paranoid <= -1.
> >
> > On the
On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
> Tracepoints are no good at all for non-privileged users
> because they need either CAP_SYS_ADMIN or
> /proc/sys/kernel/perf_event_paranoid <= -1.
>
> On the other hand, kernel software events need either
> CAP_SYS_ADMIN or
On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
Tracepoints are no good at all for non-privileged users
because they need either CAP_SYS_ADMIN or
/proc/sys/kernel/perf_event_paranoid = -1.
On the other hand, kernel software events need either
CAP_SYS_ADMIN or
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On Thu, Jun 11, 2015 at 04:15:48PM +0200, Peter Zijlstra wrote:
On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
Tracepoints are no good at all for non-privileged users
because they need either CAP_SYS_ADMIN or
/proc/sys/kernel/perf_event_paranoid = -1.
On the other hand,
On Thu, Jun 11, 2015 at 09:34:30AM -0700, Andi Kleen wrote:
On Thu, Jun 11, 2015 at 04:15:48PM +0200, Peter Zijlstra wrote:
On Tue, Jun 09, 2015 at 05:21:10PM +0300, Adrian Hunter wrote:
Tracepoints are no good at all for non-privileged users
because they need either CAP_SYS_ADMIN or
There are already two events for context switches, namely
the tracepoint sched:sched_switch and the software event
context_switches. Unfortunately neither are suitable for
use by non-privileged users for the purpose of synchronizing
hardware trace data (e.g. Intel PT) to the context switch.
There are already two events for context switches, namely
the tracepoint sched:sched_switch and the software event
context_switches. Unfortunately neither are suitable for
use by non-privileged users for the purpose of synchronizing
hardware trace data (e.g. Intel PT) to the context switch.
32 matches
Mail list logo
