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 Shameer,

On 03/07/2019 13:27, Shameerali Kolothum Thodi wrote:
>> -----Original Message-----
>> On 21/06/2019 16:57, Shameerali Kolothum Thodi wrote:
>>>> -----Original Message-----
>>>> From: James Morse [mailto:james.morse@xxxxxxx]

>> The domid bitfield not being big enough for the width of the cacheinfo id field
>> looks like
>> a bug in the existing resctrl code. Could you spin that as a patch against
>> mainline?
> 
> Yes it could be a bug. But I am not sure about the assumption on x86 platforms with
> respect to cache id width. Also any need to consider 32 bit systems at all or not.
> 
>> It won't affect any x86 system, but I don't want to 'fix' anything as part of the
>> mpam
>> support.
> 
> Does that mean the cache id width on x86 will never be >14 bits?

I have no idea. Today they're 0,1,2, so its unlikely?, but Documentation/x86/resctrl.rst's
"Cache IDs" section says "it isn't guaranteed to be a contiguous sequence", so maybe?

The problem is 'struct cacheinfo's id field is an int, its exposed via sysfs as an int,
but resctrl packs it into a smaller size. That's going to bite one day, it would be good
to fix it now we know its a problem.


>> We almost certainly need to compress the cache-id numbers down to {0,1,2} if
>> only so we
>> haven't filled all the exposed bits on day-1. (so it might not matter for arm64
>> either...)
> 
> That will be nice if we can compress it like that> I think we can leave the fix for now
> and come up with a solution when things gets really going.
> 
> Mean time I am trying to probe memory controller as well on our system and it looks
> like there are still issues.

Typo in the MBA picking code? Should be:
| if (!mpam_has_feature(mpam_feat_mbw_part, class->features) &&
|     !mpam_has_feature(mpam_feat_mbw_max, class->features)) {

It can do something useful with either of those features, but the (!part || !max)
previously forced it to have both.

(This still doesn't work on the model as its describing a 0-bit bitmap MBW_PART)


> 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/snapshot/jun

The changes in there are to avoid the known-issues when the same 'thing' is picked as both
L3 resource and the MBA resource.

I think the risk of sleeping-while-atomic if not all mpam:devices are accessible from all
CPUs in the resctrl:domain is my next highest priority issue...


Thanks,

James



[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