RE: [PATCH 13/32] Documentation, x86: Documentation for Intel resource allocation user interface

[Yu, Fenghua]

> From: Thomas Gleixner [mailto:tglx@xxxxxxxxxxxxx]
> Sent: Tuesday, July 19, 2016 5:32 AM
> On Thu, 14 Jul 2016, Luck, Tony wrote:
> > So the core part of __intel_rdt_sched_in() will look like:
> >
> > 			rdtgrp = root_rdtgroup;
> That can be done simpler. The default cpu_rdtgroup should be
> root_rdtgroup. So you spare one conditional.
> 
> Thanks
> 
> 	tglx

Hi, Thomas et al,

Do we need to consider using generic schemas format instead of the current architecture specific
schemas format?

Currently we use CBM (Cache Bit Mask) in the "schemas". This is architecture specific format.
A feedback I got is this may not be expanded to hypothetical future other architecture(s),
user/sysadmin may not have knowledge of CBM, and difficult VM migration b/w different
machines which have different length of CBM.

Our current answer to the feedback is user tool/knowledge is needed to set up schemas.
Kernel only does CBM or architecture level schemas. User management tools can be designed
to hide all kernel CBM details and allow users to allocate cache with high level knowledge
(e.g. % of cache or size of cache etc). I believe user level tool can handle this and kernel only
needs to handle minimal CBM level. This is how we have been designing this user interface.

But on the other hand, we can handle high level schemas info in kernel user interface as well.
We can introduce allocation policies to user interface. User specifies an allocation policy during
resctrl file system mount time. Each policy has its own driver in kernel. Default policy is to use
current CBM schemas that is implemented in this patch set. We can implement other drivers
and schemas format may be different in each driver. For example, % policy driver which
specifies % of L3 allocation in the schemas. Another example, size policy driver which specifies
size of L3 in the schemas. And people can write other creative policies in the future. Each driver
has its own CONFIG.

If doing this, this updated user interface can address the above concerns in kernel level plus
it can handle cases (example??) that user tool cannot handle in user space. Should we update
the current user interface to do this? Code and document changes should be about 50 lines
more on top of current patch set.

Just raise the question for open discussion.

Thanks.

-Fenghua