linux-kernel - Re: [PATCH v5 00/21] x86/resctrl: Make resctrl_arch_rmid

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] [day] [month] [year] [list]

Message-ID: <0586ab4b-e201-fbeb-927d-8ba709573b07@arm.com>
Date:   Thu, 8 Sep 2022 18:01:19 +0100
From:   James Morse <james.morse@....com>
To:     haoxin <xhao@...ux.alibaba.com>,
        Reinette Chatre <reinette.chatre@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Cc:     Fenghua Yu <fenghua.yu@...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 v5 00/21] x86/resctrl: Make resctrl_arch_rmid_read()
 return values in bytes

Hi Hao Xin,

On 07/09/2022 06:46, haoxin wrote:
> 在 2022/8/24 上午1:09, Reinette Chatre 写道:
>> On 7/3/2022 8:54 AM, Xin Hao wrote:
>>> [root@...p1bu26qv0j3ddyusot3Z p1]# cat mon_data/mon_L3_00/llc_occupancy
>>> 3833856
>>> [root@...p1bu26qv0j3ddyusot3Z p1]# cat mon_data/mon_L3_00/llc_occupancy
>>> 3620864
>>> [root@...p1bu26qv0j3ddyusot3Z p1]# cat mon_data/mon_L3_00/llc_occupancy
>>> 3727360
>>> [root@...p1bu26qv0j3ddyusot3Z p1]# cat size
>>>      MB:0=100;1=100
>>>      L3:0=3407872;1=3407872
>>>
>>> Obviously, the value has been overflowed,  Can you explain why？

>> I do not think the conclusion should immediately be that there is an
>> overflow issue. Have you perhaps run into the scenario "Notes on
>> cache occupancy monitoring and control" described in
>> Documentation/x86/resctrl.rst?
>>
>> When "memhog" starts it can allocate to the entire L3 for a while
>> before it is moved to the constrained resource group. It's cache
>> lines are not evicted as part of this move so it is not unusual for
>> it to have more lines in L3 than it is allowed to allocate into.
> 
> Yes as you said, the mon_data/mon_L3_00/llc_occupancy does not immediately become the
> value small than the set by schemata,  it may takes a few minutes to reduce to the set value.
> 
> I don't quite understand why it takes so long to see the llc_occupancy degrage.

Do you have workloads in other control groups causing cache allocations?

One of the ways this stuff can be built is for the cache to use the policy to choose which
lines to evict. The cache may already have some LRU or line-state preferences when it
comes to eviction, so it may not apply the RDT policy as the first choice.

If there is no cache pressure from outside the control group - does it matter how quickly
it takes to apply?


Thanks,

James