linux-kernel - Re: [PATCH v6 20/21] x86/resctrl: Add resctrl_rmid_realloc_limit to abstract x86's boot_cpu

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 8 Sep 2022 18:01:32 +0100
From:   James Morse <james.morse@....com>
To:     haoxin <xhao@...ux.alibaba.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        Babu Moger <Babu.Moger@....com>,
        shameerali.kolothum.thodi@...wei.com,
        D Scott Phillips OS <scott@...amperecomputing.com>,
        lcherian@...vell.com, bobo.shaobowang@...wei.com,
        tan.shaopeng@...itsu.com, Jamie Iles <quic_jiles@...cinc.com>,
        Cristian Marussi <cristian.marussi@....com>,
        xingxin.hx@...nanolis.org, baolin.wang@...ux.alibaba.com
Subject: Re: [PATCH v6 20/21] x86/resctrl: Add resctrl_rmid_realloc_limit to
 abstract x86's boot_cpu_data

Hi Hao Xin,

On 07/09/2022 07:26, haoxin wrote:
> 在 2022/9/2 下午11:48, James Morse 写道:
>> resctrl_rmid_realloc_threshold can be set by user-space. The maximum
>> value is specified by the architecture.
>>
>> Currently max_threshold_occ_write() reads the maximum value from
>> boot_cpu_data.x86_cache_size, which is not portable to another
>> architecture.
>>
>> Add resctrl_rmid_realloc_limit to describe the maximum size in bytes
>> that user-space can set the threshold to.

>> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
>> index e91afe99b763..8d15568d7121 100644
>> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
>> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
>> @@ -747,10 +752,10 @@ int rdt_get_mon_l3_config(struct rdt_resource *r)
>>   {
>>       unsigned int mbm_offset = boot_cpu_data.x86_cache_mbm_width_offset;
>>       struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
>> -    unsigned int cl_size = boot_cpu_data.x86_cache_size;
>>       unsigned int threshold;
>>       int ret;
>>   +    resctrl_rmid_realloc_limit = boot_cpu_data.x86_cache_size * 1024;

> Use SZ_1K instead ?

Sure, that's usually more readable. I didn't because the existing code doesn't, and I
wanted it to be obvious where this had come from.

If I re-post the series I'll change this.


Thanks for taking a look!

James

>>       hw_res->mon_scale = boot_cpu_data.x86_cache_occ_scale;
>>       r->num_rmid = boot_cpu_data.x86_cache_max_rmid + 1;
>>       hw_res->mbm_width = MBM_CNTR_WIDTH_BASE;
>> @@ -767,7 +772,7 @@ int rdt_get_mon_l3_config(struct rdt_resource *r)
>>        *
>>        * For a 35MB LLC and 56 RMIDs, this is ~1.8% of the LLC.
>>        */
>> -    threshold = cl_size * 1024 / r->num_rmid;
>> +    threshold = resctrl_rmid_realloc_limit / r->num_rmid;
>>         /*
>>        * Because num_rmid may not be a power of two, round the value