[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1604291320200.18257@vshiva-Udesk>
Date: Fri, 29 Apr 2016 13:21:12 -0700 (PDT)
From: Vikas Shivappa <vikas.shivappa@...ux.intel.com>
To: David Carrillo-Cisneros <davidcc@...gle.com>
cc: Peter Zijlstra <peterz@...radead.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
Tony Luck <tony.luck@...el.com>,
Stephane Eranian <eranian@...gle.com>,
Paul Turner <pjt@...gle.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch()
scheduler hook
On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote:
> (Re-sending in plain text)
>
> This hook is used in the following patch in the series to write to
> PQR_ASSOC_MSR, a msr that is utilized both by CQM/CMT and by CAT.
> Since CAT is not dependent on perf, I created this hook to start CQM
> monitoring right after other events start while keeping it independent
> of perf. The idea is to have future versions of CAT to also rely on
> this hook.
CAT did the msr write in switch_to as Peter did not want a new hook to be used.
Same could be done here.
Thanks,
Vikas
>
> On Fri, Apr 29, 2016 at 11:05 AM, David Carrillo-Cisneros
> <davidcc@...gle.com> wrote:
>> This hook is used in the following patch in the series to write to
>> PQR_ASSOC_MSR, a msr that is utilized both by CQM/CMT and by CAT. Since CAT
>> is not dependent on perf, I created this hook to start CQM monitoring right
>> after other events start while keeping it independent of perf. The idea is
>> to have future versions of CAT to also rely on this hook.
>>
>> On Fri, Apr 29, 2016 at 1:52 AM Peter Zijlstra <peterz@...radead.org> wrote:
>>>
>>> On Thu, Apr 28, 2016 at 09:43:31PM -0700, David Carrillo-Cisneros wrote:
>>>> This hook allows architecture specific code to be called at the end of
>>>> the task switch and after perf_events' context switch but before the
>>>> scheduler lock is released.
>>>>
>>>> The specific use case in this series is to avoid multiple writes to a
>>>> slow
>>>> MSR until all functions which modify such register in task switch have
>>>> finished.
>>>
>>> Yeah, no. This really need way more justification. Why can't you use the
>>> regular perf sched-in stuff for CQM?
>
Powered by blists - more mailing lists