Hi Shameer,

On 03/07/2019 13:27, Shameerali Kolothum Thodi wrote:

quoted

-----Original Message-----
On 21/06/2019 16:57, Shameerali Kolothum Thodi wrote:

quoted

quoted

-----Original Message-----
From: James Morse [mailto:james.morse@arm.com]

quoted

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.

quoted

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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel