答复: 答复: [PATCH] fs/resctrl: fix domid loss precision issue

[Rex Nie]

Ok, I apply it as patch v2, and thanks for your comment.

> -----邮件原件-----
> 发件人: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
> 发送时间: 2024年3月11日 20:18
> 收件人: Maciej Wieczor-Retman <maciej.wieczor-retman@xxxxxxxxx>; Rex Nie
> <rex.nie@xxxxxxxxxxxxxxx>
> 抄送: james.morse@xxxxxxx; fenghua.yu@xxxxxxxxx;
> reinette.chatre@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Liming Wu
> <liming.wu@xxxxxxxxxx>
> 主题: Re: 答复: [PATCH] fs/resctrl: fix domid loss precision issue
> 
> External Mail: This email originated from OUTSIDE of the organization!
> Do not click links, open attachments or provide ANY information unless you
> recognize the sender and know the content is safe.
> 
> 
> On Mon, 11 Mar 2024, Maciej Wieczor-Retman wrote:
> 
> > Thanks for the reply,
> >
> > On 2024-03-11 at 09:37:37 +0000, Rex Nie wrote:
> > >Hello,
> > >     Please kindly check my inline reply. Thanks.
> > >Best regards
> > >Rex Nie
> > >
> > >> >This will cause below issue if cache_id > 0x3fff likes:
> > >>
> > >> Is there some reason for cache_id ever being this high?
> > >>
> > >> I thought the max for cache_id was the amount of L3 caches on a
> > >> system. And I only observed it going up to 3 on some server
> > >> platforms. So not nearly in the range of 0x3fff or 16k.
> > >>
> > >It is exactly as you said on X86 platforms, but cache_Id on Arm platform is
> different.
> > >According to ACPI for mpam, cache id is used as locator for cache MSC.
> Reference to RD_PPTT_CACHE_ID definition from edk2-platforms:
> > >#define RD_PPTT_CACHE_ID(PackageId, ClusterId, CoreId, CacheType)
> \
> > >
> (                                                              \
> > >       (((PackageId) & 0xF) << 20) | (((ClusterId) & 0xFF) << 12) |
> \
> > >       (((CoreId) & 0xFF) << 4) | ((CacheType) & 0xF)
> \
> > >     )
> > >So it may be > 0x3fff on Arm platform.
> 
> Hi Rex,
> 
> Please also put that kind of knowledge into the commit message upfront. No
> need to be as verbose as you're here (with code quotes, etc.) but stating that
> some platforms use higher IDs (e.g., Arm) would be pretty useful in answering
> the question why you're doing this change (which is one of the key points of
> describing your change).
> 
> --
>  i.
> 
> > >Reference RD_PPTT_CACHE_ID from edk2-platforms:
> > >https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/
> > >SgiPkg/Include/SgiAcpiHeader.h#L202
> >
> > and thanks for clearing it up for me! I browsed some MPAM patches but
> > didn't notice cache_id was used differently on ARM.
> >
> > >
> > >> >/sys/fs/resctrl/mon_groups/p1/mon_data/mon_L3_1048564 # cat
> > >> >llc_occupancy
> > >>
> > >> How did you get this file to appear? Could you maybe show how your
> > >> mon_data directory looks like?
> > >>
> > >I found this issue on Arm FVP N1 platform and my N2 platform.
> > >
> > >Below is the steps on Arm FVP N1:
> > >mount -t resctrl resctrl / /sys/fs/resctrl cd
> > >/sys/fs/resctrl/mon_data
> > >
> > >/sys/fs/resctrl/mon_data # ls -l
> > >total 0
> > >dr-xr-xr-x    2 0        0                0 Mar 11 09:24
> mon_L3_1048564
> > >
> > >cd /sys/fs/resctrl/mon_data # cd mon_L3_1048564
> > >/sys/fs/resctrl/mon_data/mon_L3_1048564 # cat llc_occupancy
> > >cat: read error: No such file or directory
> > >
> > >Arm FVP MPAM:
> > >https://neoverse-reference-design.docs.arm.com/en/latest/mpam/mpam-re
> > >sctrl.html#memory-system-resource-partitioning-and-monitoring-mpam
> > >
> >
> >