[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <29588394-0b14-86f3-9933-1a852707c233@linux.intel.com>
Date: Tue, 21 Mar 2023 11:38:36 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Thomas Gleixner <tglx@...utronix.de>, jstultz@...gle.com,
peterz@...radead.org, mingo@...hat.com,
linux-kernel@...r.kernel.org
Cc: sboyd@...nel.org, eranian@...gle.com, namhyung@...nel.org,
ak@...ux.intel.com, adrian.hunter@...el.com,
Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [RFC PATCH V2 4/9] perf/x86: Enable post-processing monotonic raw
conversion
Hi Thomas,
On 2023-02-14 3:55 p.m., Thomas Gleixner wrote:
> On Tue, Feb 14 2023 at 15:21, Kan Liang wrote:
>> On 2023-02-14 3:02 p.m., Thomas Gleixner wrote:
>>>
>>> What guarantees that the clocksource used by the timekeeping core is
>>> actually TSC? Nothing at all. You cannot make assumptions here.
>>>
>>
>> Yes, you are right.
>> I will add a check to make sure the clocksource is TSC when perf does
>> the conversion.
>>
>> Could you please comment on whether the patch is in the right direction?
>> This V2 patch series expose the kernel internal conversion information
>> into the user space. Is it OK for you?
>
> Making the conversion info an ABI is suboptimal at best. I'm still
> trying to wrap my brain around all of this. Will reply over there once
> my confusion subsides.
>
John and I have tried a pure user-space solution (avoid exposing
internal conversion info) to convert a given TSC to a monotonic raw.
But it doesn't work well.
https://lore.kernel.org/lkml/CANDhNComKRDdZJ8SJECNdoAzQhmR3vu9yKAtp7NKDmECxff=fg@mail.gmail.com/
So, for now, there seems only two solutions.
Solution 1: Do the conversion in the kernel (Similar to V1).
https://lore.kernel.org/lkml/20230123182728.825519-1-kan.liang@linux.intel.com/
Solution 2: Expose the internal conversion information to the user space
via perf mmap and does post-processing conversion. (Implemented in this V2)
Personally, I incline the solution 1. Because
- The current monotonic raw is calculated in the kernel as well.
The solution 1 just follow the existing method. It doesn't introduce
extra overhead.
- It avoids exposing the internal timekeeping state directly to userspace.
What do you think? Are there other directions I can explore?
Thanks,
Kan
Powered by blists - more mailing lists