[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBS15h1p4gaaqJ0ExE35QcoFQ5dsVKeYcXi=jZ_9GB-BHg@mail.gmail.com>
Date: Wed, 19 Feb 2014 20:59:08 +0100
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Will Deacon <will.deacon@....com>,
Drew Richardson <drew.richardson@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnaldo <acme@...hat.com>, Pawel Moll <Pawel.Moll@....com>,
Wade Cherry <Wade.Cherry@....com>
Subject: Re: Perf Oops on 3.14-rc2
On Wed, Feb 19, 2014 at 7:36 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, Feb 19, 2014 at 07:03:13PM +0100, Stephane Eranian wrote:
>> I am trying to understand the context here.
>> Are you saying, we may call an offline CPU?
>
> Yes, that is what's happening.
>
>> I saw that sometimes you retry, sometimes you don't.
>
> I tried to do exactly what we do for the task case which is far more
> likely to fail. Could be I messed up.
>
I am not sure why you need to retry. If the CPU is offline, it is offline.
Or are you saying, you get an error, but you don't know the exact
reason, thus you keep trying? But how do you get out of this if
the CPU stays offline?
> I should probably write the function differently and have a common retry
> path instead of duplicating everything.
>
>> For perf_cgroup_attach(), we invoke task_function_call()
>> to force a PMU context switch on the task which is now monitored in cgroup mode.
>> If the CPU is offline then, the task is switched out and monitoring
>> has been stoppe,
>> no need to retry or do anything more.
>>
>> For perf_cgroup_exit(), this is pretty much the same logic.
>>
>> am I missing anything else?
>
> Don't think so; I'll add a comment there. I was just too tired to make
> sense of things.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists