lkml.org 
[lkml]   [2014]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 4/4] perf/x86/uncore: modularize Intel uncore driver
From
On Thu, Apr 24, 2014 at 12:25 PM, Yan, Zheng <zheng.z.yan@intel.com> wrote:
> On 04/24/2014 04:14 PM, Ingo Molnar wrote:
>>
>> * Stephane Eranian <eranian@google.com> wrote:
>>
>>>>> Most of the codes without comments are hardware specific codes.
>>>>> The corresponding contents in Intel uncore documents are big
>>>>> tables/lists, nothing tricky/interesting. I really don't know how
>>>>> to comment these code.
>>>>
>>>> Have a look at other PMU drivers, such as
>>>> arch/x86/kernel/cpu/perf_event_intel_rapl.c, which begin with a
>>>> general explanation attached below.
>>>
>>> I think a more useful modularization would be to split that huge
>>> file (perf_event_intel_uncore.c) into smaller files like we do for
>>> the core PMU. There is just too much stuff in this file for my own
>>> taste. Hard to navigate and I spend quite some time looking at it
>>> and modifying it!
>>>
>>> You could follow the model of the core PMU support files.
>>> You'd have a "core" file with the common routines, and then
>>> a file perf processor:
>>> - perf_event_intel_uncore.c
>>> - perf_event_intel_snbep_uncore.c
>>> - perf_event_intel_nhmex_uncore.c
>>> - perf_event_intel_ivt_uncore.c
>>> - ...
>>>
>>> Each processor specific module, would be a kernel module. The core
>>> could be one too. Note that this would not alleviate the need for
>>> some basic descriptions at the beginning of each file outlining the
>>> PMU boxes exported to a minimum.
>
> Most of hardware specific codes in the Intel uncore driver are for SandyBridge/IvyBridge/Haswell. Uncore subsystem in these CPUs are similar. One module per CPU type means we have to duplicate lots of code. I don't think it's a good idea.
>
Then, at least split nhm_ex from the rest. It is very big.

> Regards
> Yan, Zheng
>
>>
>> This structure you outline sounds like a good first step, I like it.
>>
>> To simplify this restructuring, initially we could even keep the core
>> uncore bits in the core (ha!), to not have module-on-module
>> dependencies.
>>
>> Thanks,
>>
>> Ingo
>>
>


\
 
 \ /
  Last update: 2014-04-26 13:41    [W:0.132 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site