On Fri, Apr 07, 2017 at 05:47:54PM +0800, Eli Qiao wrote:
The name doesn't really matter that much, 'scope' makes a bit more sense, 'type' is consistent with the cache bank specification, I'm fine with any. The big question here was if it is possible to have: <bank type='unified'> <control scope='code'/> <control scope='data'/> </bank> And from what you say, the simple answer is "yes". So we need to have the attribute there in the control element as well.Dan/Martin Could you please advice which should be changed ? LoL This is the output if I enabled CDP <cache> <bank id='0' level='3' type='unified' size='15360' unit='KiB' cpus='0-5'> <control min='768' unit='KiB' type='instruction' nallocations='8'/> <control min='768' unit='KiB' type='data' nallocations='8'/> </bank> <bank id='1' level='3' type='unified' size='15360' unit='KiB' cpus='6-11'> <control min='768' unit='KiB' type='instruction' nallocations='8'/> <control min='768' unit='KiB' type='data' nallocations='8'/> </bank> </cache> 1. change nallocations to allocations/max_allocation?
Dan said he's fine with both, I'd probably go for max_allocations
2. change type to scope ?
I don't care, pros for both in the previous mail.
3. change `instruction` to `code` (with CDP enabled, it called DATA/CODE which is somewhat different from /sys/fs/system/cpu/cpu*/cache/type, and I am now reuse virCacheType defined by Martin, should I define another Type)?
Neither here do I really care.
If nobody has any other opinion by the end of the day, let's just go
with scope='both/data/code', with new virCacheScope (it should map to
respective values of virCacheType so we can use that in case we will
want to) as that is enum you might want to create anyway, so that you
have easier translation from/to kernel structures using
Type{To,From}String.
P.S.: It would be clearly visible if you added the test case ;)
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
