> From: Thomas Gleixner [mailto:t...@linutronix.de] > 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
