Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1178699 > unrolled thread

Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context switches

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context  switches Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-07-07 18:20 +0200
    Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context  switches Peter Zijlstra <peterz@infradead.org> - 2015-07-08 01:00 +0200
      Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context  switches Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-07-08 15:30 +0200
        Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context  switches Adrian Hunter <adrian.hunter@intel.com> - 2015-07-08 15:50 +0200

#1178699 — Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context switches

Em Tue, Jul 07, 2015 at 05:36:14PM +0200, Peter Zijlstra escreveu:
> On Tue, Jul 07, 2015 at 10:44:37AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Jul 07, 2015 at 10:25:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Tue, Jul 07, 2015 at 11:36:39AM +0300, Adrian Hunter escreveu:
> > > > +	 * Records a context switch in or out (flagged by
> > > > +	 * PERF_RECORD_MISC_SWITCH_OUT).  next_prev_pid and next_prev_tid are
> > > > +	 * (u32)-1 unless the context is cpu-wide, in which case they are the

> > > Why carry those extra 8 bytes for non priviledged users, all the time
> > > with -1?

> > > Can't userspace cope with this, i.e. we should be able to look for those
> > > fields when the context is CPU wide, and to not look for them otherwise,
> > > no?

> > To help userspace in places where all it has is the union perf_event, we
> > can reuse one bit in misc to state that, i.e.

> >   #define PERF_RECORD_MISC_SWITCH_NEXT_PREV_PID 14

> > For instance.

> The other option would be a separate RECORD type, which might be
> simpler.

Humm, do we really need it?

I think this is just us wanting to, since we are going to add a new
record, to make it more useful for other, not right now needed,
situations, i.e. if the user is priviledged, there are two other options
to get his info, right?

So, yeah, since we have those bits doing nothing in header.misc, we
could well use them :-)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1179140

On Tue, Jul 07, 2015 at 01:13:59PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 07, 2015 at 05:36:14PM +0200, Peter Zijlstra escreveu:
> > > To help userspace in places where all it has is the union perf_event, we
> > > can reuse one bit in misc to state that, i.e.
> 
> > >   #define PERF_RECORD_MISC_SWITCH_NEXT_PREV_PID 14
> 
> > > For instance.
> 
> > The other option would be a separate RECORD type, which might be
> > simpler.
> 
> Humm, do we really need it?
> 
> I think this is just us wanting to, since we are going to add a new
> record, to make it more useful for other, not right now needed,
> situations, i.e. if the user is priviledged, there are two other options
> to get his info, right?

I was just thinking that 2 records, each with a fixed layout would be
easier to parse than 1 record with variable layout.

The record space is immense, so from that point it really doesn't
matter.

Do whatever is easiest, less mistakes get made etc. :-)

No real preference either way, as long we we've thought about it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1179809

Em Wed, Jul 08, 2015 at 12:52:40AM +0200, Peter Zijlstra escreveu:
> On Tue, Jul 07, 2015 at 01:13:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Jul 07, 2015 at 05:36:14PM +0200, Peter Zijlstra escreveu:
> > > > To help userspace in places where all it has is the union perf_event, we
> > > > can reuse one bit in misc to state that, i.e.

> > > >   #define PERF_RECORD_MISC_SWITCH_NEXT_PREV_PID 14
 
> > > > For instance.

> > > The other option would be a separate RECORD type, which might be
> > > simpler.

> > Humm, do we really need it?

> > I think this is just us wanting to, since we are going to add a new
> > record, to make it more useful for other, not right now needed,
> > situations, i.e. if the user is priviledged, there are two other options
> > to get his info, right?
 
> I was just thinking that 2 records, each with a fixed layout would be
> easier to parse than 1 record with variable layout.
 
> The record space is immense, so from that point it really doesn't
> matter.

We could do a land grab at some point there, if/when we find some reason
for that... :-)
 
> Do whatever is easiest, less mistakes get made etc. :-)
 
> No real preference either way, as long we we've thought about it.

Right, I just don't want to have two u32 carrying -1 for no reason.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1179844

On 08/07/15 16:28, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jul 08, 2015 at 12:52:40AM +0200, Peter Zijlstra escreveu:
>> On Tue, Jul 07, 2015 at 01:13:59PM -0300, Arnaldo Carvalho de Melo wrote:
>>> Em Tue, Jul 07, 2015 at 05:36:14PM +0200, Peter Zijlstra escreveu:
>>>>> To help userspace in places where all it has is the union perf_event, we
>>>>> can reuse one bit in misc to state that, i.e.
> 
>>>>>   #define PERF_RECORD_MISC_SWITCH_NEXT_PREV_PID 14
>  
>>>>> For instance.
> 
>>>> The other option would be a separate RECORD type, which might be
>>>> simpler.
> 
>>> Humm, do we really need it?
> 
>>> I think this is just us wanting to, since we are going to add a new
>>> record, to make it more useful for other, not right now needed,
>>> situations, i.e. if the user is priviledged, there are two other options
>>> to get his info, right?
>  
>> I was just thinking that 2 records, each with a fixed layout would be
>> easier to parse than 1 record with variable layout.
>  
>> The record space is immense, so from that point it really doesn't
>> matter.
> 
> We could do a land grab at some point there, if/when we find some reason
> for that... :-)
>  
>> Do whatever is easiest, less mistakes get made etc. :-)
>  
>> No real preference either way, as long we we've thought about it.
> 
> Right, I just don't want to have two u32 carrying -1 for no reason.

So you'd be OK with 2 RECORD types?

I will see what is involved.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web