[libvirt] [PATCH RFC 1/2] Resctrl: Add new xml element to support cache tune

Martin Kletzander mkletzan at redhat.com
Thu Jun 22 12:41:47 UTC 2017


On Thu, Jun 22, 2017 at 01:24:29PM +0800, Eli Qiao wrote:
>hi Martin
>
>It’s really nice of you to help reviewing the mass code. Thanks.
>
>I don’t find a better way to split patch.
>
>
>On Wednesday, 21 June 2017 at 9:53 PM, Martin Kletzander wrote:
>
>> On Mon, Jun 12, 2017 at 05:48:40PM +0800, Eli Qiao wrote:
>> > This patch adds new xml element to support cache tune as:
>> >
>> > <cputune>
>> > ...
>> > <cachetune id='0' cache_id='0' level='3' type='both' size='2816' unit='KiB'
>> > vcpus='1,2'/>
>> >
>>
>>
>> The cache_id automatically implies level and type. Either have one or
>> the other. I know we talked about this already (maybe multiple times),
>> but without any clear outcome. For me the sensible thing is to have
>> level and type as that doesn't need to be changed when moving between
>> hosts, and if it cannot be migrated, then it's properly checked.
>>
>Think about this case, if the VM has numa setting, the VM has multiple vcpu
>running across sockets, if we don’t specify cache_id (cache id stand for
>on which Socket/Cache), how can we know on which Socket we allocation for the VM?
>

I missed this.  Ye, you're right, thanks for showing that with a use
case.  We could then require only the cache_id and automatically fill
in level and type.  Migration (or rather any start) should then fail if
that cache_id doesn't correspond to the level and type requested.  I
still can't find a reason for 'id', though.

>I can image there’s 2 cases:
>
>1. if we don’t specify vcpus, and our host have 2 or more Socket, we have this xml define
>
> <cachetune id='0' level='3' type='both' size='2816' unit=‘KiB’>
>
>We allocate 2816 KiB cache on all of the Socket/Cache.
>
>2. if we specify vcpus
> <cachetune id='0' level='3' type='both' size='2816' unit=‘KiB’, vcpus=‘1,2'>
>
> <cachetune id=‘1' level='3' type='both' size=‘5632' unit=‘KiB’, vcpus=‘3,4’>
>
>We need to make sure we vcpu 1, 2 are mapped to Socket/Cache 0 and 3,4 on Socket/Cache 1.
>So that vcpus running on Socket/Cache 0 has 2816 KiB cache allocated and vcpus running on
>Socket/Cache 1 has 5632 KiB cache allocated.
>
>Does it make sense?
>
>>
>
>> >
>> > virDomainCputune cputune;
>> >
>> > + virDomainCachetune cachetune;
>> > +
>> >
>>
>>
>> It is part of cputune in the XML, why not here?
>
>Oh yes, I will rethink how to simple the domain cache tune.
>>
>> > virDomainNumaPtr numa;
>> > virDomainResourceDefPtr resource;
>> > virDomainIdMapDef idmap;
>> > --
>> > 1.9.1
>> >
>> > --
>> > libvir-list mailing list
>> > libvir-list at redhat.com (mailto:libvir-list at redhat.com)
>> > https://www.redhat.com/mailman/listinfo/libvir-list
>> >
>>
>>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com (mailto:libvir-list at redhat.com)
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170622/4d8482f5/attachment-0001.sig>


More information about the libvir-list mailing list