Stephane Eranian writes:
>>
> I don't understand why this need to be so complicated.
> Maybe just change the error code in case of group
> overcommitment? That way, the tool could distinguish
> and report the appropriate error message.
The existing errno is an ABI.
Also that would handle this
Stephane Eranian eran...@google.com writes:
I don't understand why this need to be so complicated.
Maybe just change the error code in case of group
overcommitment? That way, the tool could distinguish
and report the appropriate error message.
The existing errno is an ABI.
Also that would
On Mon, Dec 2, 2013 at 4:23 PM, Andi Kleen wrote:
>> Something like below? user space supply buffer for error string.
>
> That would work, although I was thinking of making it a more
> generic mechanism (store it into task_struct, have a extra
> syscall to retrieve)
>
I don't understand why this
> Something like below? user space supply buffer for error string.
That would work, although I was thinking of making it a more
generic mechanism (store it into task_struct, have a extra
syscall to retrieve)
-Andi
>
> jirka
>
>
> ---
> diff --git a/include/uapi/linux/perf_event.h
Something like below? user space supply buffer for error string.
That would work, although I was thinking of making it a more
generic mechanism (store it into task_struct, have a extra
syscall to retrieve)
-Andi
jirka
---
diff --git a/include/uapi/linux/perf_event.h
On Mon, Dec 2, 2013 at 4:23 PM, Andi Kleen a...@linux.intel.com wrote:
Something like below? user space supply buffer for error string.
That would work, although I was thinking of making it a more
generic mechanism (store it into task_struct, have a extra
syscall to retrieve)
I don't
On Fri, Nov 29, 2013 at 2:52 PM, Jiri Olsa wrote:
> On Fri, Nov 29, 2013 at 02:43:35PM +0100, Stephane Eranian wrote:
>> On Fri, Nov 29, 2013 at 2:33 PM, Jiri Olsa wrote:
>> > On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
>> >> > I'd say that the default behavior should be what
On Fri, Nov 29, 2013 at 02:43:35PM +0100, Stephane Eranian wrote:
> On Fri, Nov 29, 2013 at 2:33 PM, Jiri Olsa wrote:
> > On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
> >> > I'd say that the default behavior should be what Jiri implemented: get
> >> > the most out of the situation
On Fri, Nov 29, 2013 at 2:33 PM, Jiri Olsa wrote:
> On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
>> > I'd say that the default behavior should be what Jiri implemented: get
>> > the most out of the situation and inform. But you are right in that
>> > 'forcing' all elements of a
On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
> > I'd say that the default behavior should be what Jiri implemented: get
> > the most out of the situation and inform. But you are right in that
> > 'forcing' all elements of a group to be valid should be possible as
> > well - if a
On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
I'd say that the default behavior should be what Jiri implemented: get
the most out of the situation and inform. But you are right in that
'forcing' all elements of a group to be valid should be possible as
well - if a special
On Fri, Nov 29, 2013 at 2:33 PM, Jiri Olsa jo...@redhat.com wrote:
On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
I'd say that the default behavior should be what Jiri implemented: get
the most out of the situation and inform. But you are right in that
'forcing' all elements of
On Fri, Nov 29, 2013 at 02:43:35PM +0100, Stephane Eranian wrote:
On Fri, Nov 29, 2013 at 2:33 PM, Jiri Olsa jo...@redhat.com wrote:
On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
I'd say that the default behavior should be what Jiri implemented: get
the most out of the
On Fri, Nov 29, 2013 at 2:52 PM, Jiri Olsa jo...@redhat.com wrote:
On Fri, Nov 29, 2013 at 02:43:35PM +0100, Stephane Eranian wrote:
On Fri, Nov 29, 2013 at 2:33 PM, Jiri Olsa jo...@redhat.com wrote:
On Sat, Nov 16, 2013 at 07:41:34PM -0800, Andi Kleen wrote:
I'd say that the default
> I'd say that the default behavior should be what Jiri implemented: get
> the most out of the situation and inform. But you are right in that
> 'forcing' all elements of a group to be valid should be possible as
> well - if a special perf stat option or event format is used.
When something is
I'd say that the default behavior should be what Jiri implemented: get
the most out of the situation and inform. But you are right in that
'forcing' all elements of a group to be valid should be possible as
well - if a special perf stat option or event format is used.
When something is
On Fri, Nov 15, 2013 at 4:08 PM, Vince Weaver wrote:
> On Fri, 15 Nov 2013, Ingo Molnar wrote:
>>
>> Btw., does the kernel side currently support discovery of such
>> impossible group scheduling constraints at group setup time? If not
>> then it probably should and it should reject them straight
On Fri, 15 Nov 2013, Ingo Molnar wrote:
>
> Btw., does the kernel side currently support discovery of such
> impossible group scheduling constraints at group setup time? If not
> then it probably should and it should reject them straight away.
It does not, or at least I'm pretty sure it can't
On Fri, Nov 15, 2013 at 12:52 PM, Peter Zijlstra wrote:
> On Fri, Nov 15, 2013 at 11:34:05AM +0100, Ingo Molnar wrote:
>> That brings up an interesting question: what is better for users, if
>> we schedule as many as we can and say 'not supported' to the rest
>> (current behavior), or if we fail
On Fri, Nov 15, 2013 at 11:34:05AM +0100, Ingo Molnar wrote:
> That brings up an interesting question: what is better for users, if
> we schedule as many as we can and say 'not supported' to the rest
> (current behavior), or if we fail the whole group?
>
> I'd say that the default behavior
On Fri, Nov 15, 2013 at 11:34:05AM +0100, Ingo Molnar wrote:
> That brings up an interesting question: what is better for users, if
> we schedule as many as we can and say 'not supported' to the rest
> (current behavior), or if we fail the whole group?
Obviously fail the whole group :-)
--
To
On Fri, Nov 15, 2013 at 11:13:27AM +0100, Stephane Eranian wrote:
> On Fri, Nov 15, 2013 at 11:05 AM, Peter Zijlstra wrote:
> > On Fri, Nov 15, 2013 at 07:34:57AM +0100, Ingo Molnar wrote:
> >> Btw., does the kernel side currently support discovery of such
> >> impossible group scheduling
On Fri, Nov 15, 2013 at 11:34 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar wrote:
>> >
>> > * Stephane Eranian wrote:
>> >
>> >> Jiri,
>> >>
>> >> I was trying the grouping support in perf stat and I was surprised
>> >> to see that if I
* Stephane Eranian wrote:
> On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar wrote:
> >
> > * Stephane Eranian wrote:
> >
> >> Jiri,
> >>
> >> I was trying the grouping support in perf stat and I was surprised
> >> to see that if I create a group that is too big to be scheduled, and
> >> where
On Fri, Nov 15, 2013 at 11:05 AM, Peter Zijlstra wrote:
> On Fri, Nov 15, 2013 at 07:34:57AM +0100, Ingo Molnar wrote:
>> Btw., does the kernel side currently support discovery of such
>> impossible group scheduling constraints at group setup time?
>
> Up to a point.
>
It is only looking at the
On Fri, Nov 15, 2013 at 07:34:57AM +0100, Ingo Molnar wrote:
> Btw., does the kernel side currently support discovery of such
> impossible group scheduling constraints at group setup time?
Up to a point.
> If not
> then it probably should and it should reject them straight away.
We do I
On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> Jiri,
>>
>> I was trying the grouping support in perf stat and I was surprised
>> to see that if I create a group that is too big to be scheduled, and
>> where only N out of P events can fit, perf stat still
On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar mi...@kernel.org wrote:
* Stephane Eranian eran...@google.com wrote:
Jiri,
I was trying the grouping support in perf stat and I was surprised
to see that if I create a group that is too big to be scheduled, and
where only N out of P events can
On Fri, Nov 15, 2013 at 07:34:57AM +0100, Ingo Molnar wrote:
Btw., does the kernel side currently support discovery of such
impossible group scheduling constraints at group setup time?
Up to a point.
If not
then it probably should and it should reject them straight away.
We do I think,
On Fri, Nov 15, 2013 at 11:05 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Nov 15, 2013 at 07:34:57AM +0100, Ingo Molnar wrote:
Btw., does the kernel side currently support discovery of such
impossible group scheduling constraints at group setup time?
Up to a point.
It is only
* Stephane Eranian eran...@google.com wrote:
On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar mi...@kernel.org wrote:
* Stephane Eranian eran...@google.com wrote:
Jiri,
I was trying the grouping support in perf stat and I was surprised
to see that if I create a group that is too big
On Fri, Nov 15, 2013 at 11:34 AM, Ingo Molnar mi...@kernel.org wrote:
* Stephane Eranian eran...@google.com wrote:
On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar mi...@kernel.org wrote:
* Stephane Eranian eran...@google.com wrote:
Jiri,
I was trying the grouping support in perf stat
On Fri, Nov 15, 2013 at 11:13:27AM +0100, Stephane Eranian wrote:
On Fri, Nov 15, 2013 at 11:05 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Nov 15, 2013 at 07:34:57AM +0100, Ingo Molnar wrote:
Btw., does the kernel side currently support discovery of such
impossible group
On Fri, Nov 15, 2013 at 11:34:05AM +0100, Ingo Molnar wrote:
That brings up an interesting question: what is better for users, if
we schedule as many as we can and say 'not supported' to the rest
(current behavior), or if we fail the whole group?
Obviously fail the whole group :-)
--
To
On Fri, Nov 15, 2013 at 11:34:05AM +0100, Ingo Molnar wrote:
That brings up an interesting question: what is better for users, if
we schedule as many as we can and say 'not supported' to the rest
(current behavior), or if we fail the whole group?
I'd say that the default behavior should be
On Fri, Nov 15, 2013 at 12:52 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Nov 15, 2013 at 11:34:05AM +0100, Ingo Molnar wrote:
That brings up an interesting question: what is better for users, if
we schedule as many as we can and say 'not supported' to the rest
(current behavior),
On Fri, 15 Nov 2013, Ingo Molnar wrote:
Btw., does the kernel side currently support discovery of such
impossible group scheduling constraints at group setup time? If not
then it probably should and it should reject them straight away.
It does not, or at least I'm pretty sure it can't if
On Fri, Nov 15, 2013 at 4:08 PM, Vince Weaver vi...@deater.net wrote:
On Fri, 15 Nov 2013, Ingo Molnar wrote:
Btw., does the kernel side currently support discovery of such
impossible group scheduling constraints at group setup time? If not
then it probably should and it should reject them
* Stephane Eranian wrote:
> Jiri,
>
> I was trying the grouping support in perf stat and I was surprised
> to see that if I create a group that is too big to be scheduled, and
> where only N out of P events can fit, perf stat still yields counts
> for the N events. I was expecting 0 counts
Jiri,
I was trying the grouping support in perf stat and I was surprised
to see that if I create a group that is too big to be scheduled, and
where only N out of P events can fit, perf stat still yields counts
for the N events. I was expecting 0 counts or .
The kernel semantic is to schedule all
Jiri,
I was trying the grouping support in perf stat and I was surprised
to see that if I create a group that is too big to be scheduled, and
where only N out of P events can fit, perf stat still yields counts
for the N events. I was expecting 0 counts or not supported.
The kernel semantic is to
* Stephane Eranian eran...@google.com wrote:
Jiri,
I was trying the grouping support in perf stat and I was surprised
to see that if I create a group that is too big to be scheduled, and
where only N out of P events can fit, perf stat still yields counts
for the N events. I was
42 matches
Mail list logo
