Only Cascadelake-AP CPUs appear to report "die_id" values != 0 on Linux
right now - AMD EPYC's don't report "die_id" (at least with Fedora 31
kernel). Lacking access to Cascadelake-AP CPUs, this test data was from
a Fedora 31 QEMU guest launched with
-cpu qemu64 -smp sockets=2,dies=3,cores=2,threads=1
Ideally we'd replace this data with some from a real machine reporting
"die_id", to ensure we're not mislead by QEMU's impl.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Update the host CPU code to report the die_id in the NUMA topology
capabilities. On systems with multiple dies, this fixes the bug
where CPU cores can't be distinguished:
<cpus num='12'>
<cpu id='0' socket_id='0' core_id='0' siblings='0'/>
<cpu id='1' socket_id='0' core_id='1' siblings='1'/>
<cpu id='2' socket_id='0' core_id='0' siblings='2'/>
<cpu id='3' socket_id='0' core_id='1' siblings='3'/>
</cpus>
Notice how core_id is repeated within the scope of the same socket_id.
It now reports
<cpus num='12'>
<cpu id='0' socket_id='0' die_id='0' core_id='0' siblings='0'/>
<cpu id='1' socket_id='0' die_id='0' core_id='1' siblings='1'/>
<cpu id='2' socket_id='0' die_id='1' core_id='0' siblings='2'/>
<cpu id='3' socket_id='0' die_id='1' core_id='1' siblings='3'/>
</cpus>
So core_id is now unique within a (socket_id, die_id) pair.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This patch is introducing cache monitor(CMT) to cache and
memory bandwidth monitor(MBM) for monitoring CPU memory
bandwidth.
The host capability of the two monitors is also introduced
in this patch.
For CMT, the host capability is shown like:
<host>
...
<cache>
<bank id='0' level='3' type='both' size='15' unit='MiB' cpus='0-5'>
<control granularity='768' min='1536' unit='KiB' type='both' maxAllocs='4'/>
</bank>
<monitor level='3' 'reuseThreshold'='270336' maxMonitors='176'>
<feature name='llc_occupancy'/>
</monitor>
</cache>
...
</host>
For MBM, the capability is shown like this:
<host>
...
<memory_bandwidth>
<node id='1' cpus='6-11'>
<control granularity='10' min ='10' maxAllocs='4'/>
</node>
<monitor maxMonitors='176'>
<feature name='mbm_total_bytes'/>
<feature name='mbm_local_bytes'/>
</monitor>
</memory_bandwidth>
...
</host>
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The latter are no longer used by libvirt, and the former
never were; moreover, both have a corresponding *_list
file which we can manipulate very conveniently using our
bitmap APIs, so dropping them makes sure in the future
developers will look into that rather than trying to
parse the kernel binary bitmaps.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Add new XML section to report host's memory bandwidth allocation
capability. The format as below example:
<host>
.....
<memory_bandwidth>
<node id='0' cpus='0-19'>
<control granularity='10' min ='10' maxAllocs='8'/>
</node>
</memory_bandwidth>
</host>
granularity ---- granularity of memory bandwidth, unit percentage.
min ---- minimum memory bandwidth allowed, unit percentage.
maxAllocs ---- maximum memory bandwidth allocation group supported.
Signed-off-by: Bing Niu <bing.niu@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If all we achieve is reducing the depth by one for a single
test case, the additional complexity (not to mention breaking
the principle of least surprise) is not worth it: let's use
simpler, more predictable code instead.
This basically reverts fec6e4c48c (with a few adjustments).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Basically the `cpus` and `tasks` files are not needed, and I've witnessed on a
real system that the schemata file may have spaces prepended to a line, so let's
adjust at least one test so that it reflects what can happen. Also `000`
allocation is invalid and a full mask means it's all free. So adjust for that
too.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since we don't pack symlinks we cannot have recursive loops in them. Since we
need one directory to be in tests/vircaps2xmldata/linux-caches/, instead of
creating a symlink, just move the files in that directory and adjust tests.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This doesn't add very much value for now, but future test for virresctrl will
take information from vircaps2xmldata (since it is dependent on the same info
then why duplicate it) and this particular use case helps us cover bit more of
the code regarding proper formatting and handling errors. And one more test for
vircaps2xmltest doesn't hurt either.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This patch modifies some not yet used test data so that the adding a test using
this data is a clean patch and not an addition of huge file with some
adjustments in small files that will be hidden in the middle of that commit.
These changes include:
- Add system dir in vircaps2xmldata/linux-caches
Back when data for systems with resctrl support were added they had the
/sys/fs/system directory put into a system/ subdir of the test and
/sys/fs/resctrl in a resctrl/ subdir of that test. However, if we also want a
negative test for the resctrl (requesting allocation on a system that does not
support resctrl), we need one a test case with any sensible (with cache info)
system/ subdir and no resctrl/ one. Easiest way is to add a
system -> . symlink into existing test case.
- Change default group schemata for linux-resctrl and linux-resctrl-cdp
That way we can fit some allocation in.
- Remove one cache from resctrl-skx's schemata and make some room for
allocations
That system already has only one cache, so that file was wrong anyway. We
have a version with 2 caches already (linux-resctrl-skx-twocaches), so this
will also add variety to future tests.
- Add some empty allocation for resctrl-skx
Just to have slightly more coverage and variety. We can be sure nothing bad
happens if such allocation exists in case we have that in the tests.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
On some platforms the number of bits in the cbm_mask might not be
divisible by 4 (and not even by 2), so we need to properly count the
bits. Similar file, min_cbm_bits, is properly parsed and used, but if
the number is greater than one, we lose the information about
granularity when reporting the data in capabilities. For that matter
always report granularity, but if it is not the same as the minimum,
add that information in there as well.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Add info from yet another machine, this time with resctrl data so that
we can extend tests easily in a test-driven way.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
We're only adding only info about L3 caches, we can add more
later (just by changing one line), but for now that's more than enough
without overwhelming anyone.
XML snippet of how this should look like (also seen as part of the commit):
<cache>
<bank id='0' level='3' type='both' size='8192' unit='KiB' cpus='0-7'/>
</cache>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Instead of generating all of the capabilities, let's test more of our
code by probing sysfs data. This test needs quite some mocking for
now, but it paves the road for more future enhancements (hugepages
probing, for example).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Bit more test data, this time with complete info copied, mainly with
cache information, so we can easily add tests for it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
For now only one test is introduced. It's purpose in life
is to check we don't break NUMA host distances XML format.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Daniel P. Berrangé