Messages in this thread | | | Date | Wed, 7 Sep 2022 13:46:17 +0800 | Subject | Re: [PATCH v5 00/21] x86/resctrl: Make resctrl_arch_rmid_read() return values in bytes | From | haoxin <> |
| |
在 2022/8/24 上午1:09, Reinette Chatre 写道: > Hi, > > On 7/3/2022 8:54 AM, Xin Hao wrote: >> Hi james, >> >> I have a review all of the patches, it looks goot to me, but i also test them once again, i have a little confusion with my test. >> >> # mkdir p1 >> >> # echo "L3:0=001;1=001" > p1/schemata >> >> # [root@iZbp1bu26qv0j3ddyusot3Z p1]# cat schemata >> MB:0=100;1=100 >> L3:0=001;1=001 >> >> # memhog -r1000000 1000m > /mnt/log & >> >> [1] 53023 >> [root@iZbp1bu26qv0j3ddyusot3Z p1]# echo 53023 > tasks >> [ >> [root@iZbp1bu26qv0j3ddyusot3Z p1]# cat mon_data/mon_L3_00/llc_occupancy >> 3833856 >> [root@iZbp1bu26qv0j3ddyusot3Z p1]# cat mon_data/mon_L3_00/llc_occupancy >> 3620864 >> [root@iZbp1bu26qv0j3ddyusot3Z p1]# cat mon_data/mon_L3_00/llc_occupancy >> 3727360 >> [root@iZbp1bu26qv0j3ddyusot3Z p1]# cat size >> MB:0=100;1=100 >> L3:0=3407872;1=3407872 >> >> Obviously, the value has been overflowed, Can you explain why? > Are you seeing different behavior before and after you apply this > series? No,they have the same test result。 > > 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.
> > Understanding the occupancy values require understanding of the workload > as well as the system environment. > > Depending on the workload's data usage (for example if it keeps loading > new data - note that if the workload keeps loading the same data and the > data is already present in an area of cache that the workload cannot > allocate into then the data read would still result in a cache hit for the > workload, the data would not be moved to the area the > workload can allocate into) and other workloads on the system (there is > other load present also that evicts the lines owned by the workload) the > L3 occupancy rate should go down after a while to match the space it > can allocate into. > > Reinette
| |