linux-kernel - Re: [PATCH 2/3] perf/x86/amd/uncore: Dynamically allocate uncore counters

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]

Date:   Thu, 12 Jan 2017 18:48:40 -0600
From:   "Natarajan, Janakarajan" <Janakarajan.Natarajan@....com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Subject: Re: [PATCH 2/3] perf/x86/amd/uncore: Dynamically allocate uncore
 counters


On 1/12/2017 3:20 AM, Peter Zijlstra wrote:
> On Wed, Jan 11, 2017 at 10:02:17AM -0600, Janakarajan Natarajan wrote:
>> This patch updates the AMD uncore driver to support AMD Family17h
>> processors. In Family17h, there are two extra last level cache counters.
>> The counters are, therefore, allocated dynamically based on the family.
>>
>> The cpu hotplug up callback function is refactored to better manage
>> failure conditions.
>>
>> Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@....com>
>> ---
>>   arch/x86/events/amd/uncore.c | 141 +++++++++++++++++++++++++++++++------------
>>   1 file changed, 104 insertions(+), 37 deletions(-)
>>
>> diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
>> index 24c8537..7ab92f7 100644
>> --- a/arch/x86/events/amd/uncore.c
>> +++ b/arch/x86/events/amd/uncore.c
>> @@ -22,13 +22,16 @@
>>   
>>   #define NUM_COUNTERS_NB		4
>>   #define NUM_COUNTERS_L2		4
>> -#define MAX_COUNTERS		NUM_COUNTERS_NB
>> +#define NUM_COUNTERS_L3		6
>>   
>>   #define RDPMC_BASE_NB		6
>>   #define RDPMC_BASE_LLC		10
>>   
>>   #define COUNTER_SHIFT		16
>>   
>> +static int num_counters_llc;
>> +static int num_counters_nb;
>> +
>>   static HLIST_HEAD(uncore_unused_list);
>>   
>>   struct amd_uncore {
>> @@ -40,7 +43,7 @@ struct amd_uncore {
>>   	u32 msr_base;
>>   	cpumask_t *active_mask;
>>   	struct pmu *pmu;
>> -	struct perf_event *events[MAX_COUNTERS];
>> +	struct perf_event **events;
>>   	struct hlist_node node;
>>   };
> Why bother with the dynamic allocation crud? Why not simply set
> MAX_COUNTERS to 6 and be happy?
My reasoning behind using dynamic allocation was to prevent memory from
being allocated when not needed on a per cpu basis. If memory isn't a
consideration, I can send a v2 without the dynamic memory allocation.