linux-kernel - Re: [PATCH v2 4/4] perf/x86/uncore: modularize Intel uncore driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5358E982.4030106@intel.com>
Date:	Thu, 24 Apr 2014 18:37:54 +0800
From:	"Yan, Zheng" <zheng.z.yan@...el.com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH v2 4/4] perf/x86/uncore: modularize Intel uncore driver

On 04/24/2014 06:36 PM, Stephane Eranian wrote:
> On Thu, Apr 24, 2014 at 12:25 PM, Yan, Zheng <zheng.z.yan@...el.com> wrote:
>> On 04/24/2014 04:14 PM, Ingo Molnar wrote:
>>>
>>> * Stephane Eranian <eranian@...gle.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.

Ok, will do.

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
>>>
>>

--
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/