RE: MPAM branch verification (was RE: [RFC PATCH 2/2] ACPI / PPTT: cacheinfo: Label caches based on fw_token)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi James,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: 15 August 2019 11:38
> To: 'James Morse' <james.morse@xxxxxxx>
> Cc: Vijaya Kumar K <vkilari@xxxxxxxxxxxxxx>; Lorenzo Pieralisi
> <lorenzo.pieralisi@xxxxxxx>; Tomasz Nowicki
> <Tomasz.Nowicki@xxxxxxxxxx>; Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx>;
> Guohanjun (Hanjun Guo) <guohanjun@xxxxxxxxxx>; Linuxarm
> <linuxarm@xxxxxxxxxx>; Jeremy Linton <jeremy.linton@xxxxxxx>;
> linux-acpi@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Sudeep Holla
> <sudeep.holla@xxxxxxx>; wangxiongfeng (C)
> <wangxiongfeng2@xxxxxxxxxx>; Richard Ruigrok
> <rruigrok@xxxxxxxxxxxxxxxx>; 'bobo.shaobowang@xxxxxxxxxx'
> <bobo.shaobowang@xxxxxxxxxx>
> Subject: RE: MPAM branch verification (was RE: [RFC PATCH 2/2] ACPI / PPTT:
> cacheinfo: Label caches based on fw_token)
 
[...]

> 
> I think what happens on our hardware is, the MBA reports PMG_MAX = 0 and
> that
> upsets mpam_pmg_bits() -->ilog2(). I am not entirely sure whether PMG_MAX=
> 0 is
> allowed as per spec when the resource reports HAS_MSMON =1. But hasn't
> found
> anything in spec that forbids this as the filter is a combination of PRATID:PMG.
> 
> I have a temp hack here to keep it going,
> 
> https://github.com/hisilicon/kernel-dev/commit/5e0881c4cdded4066dfac7603
> c53242385417a3a
> 
> >
> > > I will debug and update if it really is a problem. Please
> > > let me know if you have any plans to update the branch so that I can try the
> > latest.
> >
> > I hope to push a new version by the end of June. (whoosh! There goes June).
> >
> http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/mpam/s
> > napshot/jun
> 
> Thanks for that. I am using this now. (And I see a more recent one
> mpam/5.3-tmp
> now. Has anything changed other than rebase?)
> 
> >
> > The changes in there are to avoid the known-issues when the same 'thing' is
> > picked as both
> > L3 resource and the MBA resource.
> 
> Now with the above fix for PMG_MAX=0, I am hitting another issue.
> mount -t resctrl resctrl /sys/fs/resctrl fails with "File exists" error.
> 
> Debugging points to,
> rdt_get_tree()
>   mkdir_mondata_all()
>     mkdir_mondata_subdir_alldom()
>       mkdir_mondata_subdir()
>         mon_addfile()
> 
> It looks like r->evt_list gets corrupted somehow and has duplicate entries. I
> haven’t
> gone into the bottom of this issue, but please let me know if you have any idea.

I had few dirty hacks[1] to fix the above and some other issues found, so that it
detects both L3 and MB on our platforms. Now able to mount the resctrl fs
with both L3 and MBA resource. But full verification is still pending.

Between, just thought of checking with you, is there any plan to resume/revive the
MPAM support upstream[2] anytime soon? Appreciate if you could share your plan
on this.

Thanks,
Shameer

[1] https://github.com/hisilicon/kernel-dev/commits/private-mpam-dbg-snapshot-jun
[2] https://lkml.org/lkml/2018/8/24/261







[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux