Messages in this thread | | | Date | Thu, 24 Apr 2014 12:36:01 +0200 | Subject | Re: [PATCH v2 4/4] perf/x86/uncore: modularize Intel uncore driver | From | Stephane Eranian <> |
| |
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 >> >
| |