[libvirt][PATCH v4 0/3] introduce 'restrictive' mode in numatune

[Martin Kletzander]

On Thu, Mar 25, 2021 at 08:36:17AM +0000, Daniel P. Berrangé wrote:
>On Wed, Mar 24, 2021 at 09:46:23PM +0100, Martin Kletzander wrote:
>> On Tue, Mar 23, 2021 at 09:48:02AM +0000, Daniel P. Berrangé wrote:
>> > On Tue, Mar 23, 2021 at 10:59:02AM +0800, Luyao Zhong wrote:
>> > > Before this patch set, numatune only has three memory modes:
>> > > static, interleave and prefered. These memory policies are
>> > > ultimately set by mbind() system call.
>> > >
>> > > Memory policy could be 'hard coded' into the kernel, but none of
>> > > above policies fit our requirment under this case. mbind() support
>> > > default memory policy, but it requires a NULL nodemask. So obviously
>> > > setting allowed memory nodes is cgroups' mission under this case.
>> > > So we introduce a new option for mode in numatune named 'restrictive'.
>> > >
>> > > <numatune>
>> > >    <memory mode="restrictive" nodeset="1-4,^3"/>
>> > >    <memnode cellid="0" mode="restrictive" nodeset="1"/>
>> > >    <memnode cellid="2" mode="restrictive" nodeset="2"/>
>> > > </numatune>
>> >
>> > 'restrictive' is rather a wierd name and doesn't really tell me what
>> > the memory policy is going to be. As far as I can tell from the
>> > patches, it seems this causes us to not set any memory alllocation
>> > policy at all. IOW, we're using some undefined host default policy.
>> >
>> > Given this I think we should be calling it either "none" or "default"
>> >
>>
>> I was against "default" because having such option possible, but the actual
>> default being different sounds stupid.  Similarly "none" sounds like no
>> restrictions are applied or that it is the same as if nothing was specified.  It
>> is funny to imagine the situation when I am explaining to someone how to achieve
>> this solution:
>>
>>   "The default is 'strict', you need to explicitly set it to 'default'."
>
>These patches aren't claiming the default is strict though - they're saying
>the default is whatever the kernel has been configured to be.  The kernel
>could apply interleave, or preferred or strict.  So using "default" as the
>term is fine, because we explicitly aren't guaranteing which behaviour is
>used.
>

Sorry, I was not clear.  Our (libvirt) current default is "strict".
That's why it seems weird to have that new value be called "default".

>
>Regards,
>Daniel
>-- 
>|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
>|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
>|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210325/8850db8a/attachment-0001.sig>