Re: [PATCH v2 12/16] libxl: get and set soft affinity

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3931 bytes --]

On gio, 2013-11-14 at 16:25 +0000, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 12/16] libxl: get and set soft affinity"):
> > On 14/11/13 15:11, Ian Jackson wrote:
> > > So perhaps we should have a singe function that can change the
> > > cpupool, hard affinity, and soft affinity, all at once ?
> > 
> > I think this is probably a good idea.  Would it make sense to basically 
> > have libxl_[gs]et_vcpuaffinity2(), which takes a parameter that can 
> > specify that the mask is for either hard, soft, or both?
> 
> No, it needs to take at least two separate parameters for the hard and
> soft masks, because the toolstack might want to set the hard affinity
> and soft affinity to different values, without having to think
> carefully about ordering these calls to avoid generating spurious
> warnings and incompatible arrangements.
> 
Ok, what about if I provide both?

Something like this:

int libxl_set_vcpuaffinity2(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
                            const libxl_bitmap *cpumap, int flags)
{
    flags & HARD
        <set_hard_affinity>(domid, vcpuid, cpumap)
    flags & SOFT
        <set_soft_affinity>(domid, vcpuid, cpumap)

    <check_ecpumap_out_and_warn>
}

int libxl_set_vcpuaffinity3(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
                            const libxl_bitmap *cpumap_hard,
                            const libxl_bitmap *cpumap_soft)
{
    <set_hard_affinity>(domid, vcpuid, cpumap_hard)

    <set_soft_affinity>(domid, vcpuid, cpumap_soft)

    <check_ecpumap_out_and_warn>
}

This ought to allow both the use case:
 1. when one is only want to change one (or both to the same value),
    and is ok with being WARN'ed if that result in an inconsistent state
 2. when one wants to land directly in a specific state, which requires
    changing both, each one to its own value, and only want to be
    WARN'ed _iff_ that final state is inconsistent

I've already an half backed updated series doing right this, but I'll be
working far from my testbox in the morning, so I'll complete the testing
and send it in the afternoon, ok?

> I think this probably applies to cpupool changes too.  So perhaps the
> function should look a bit like setresuid or something: it should take
> an optional new cpupool (is there a sentinel value that can be used to
> mean "no change"?), an optional new soft mask, and an optional new
> hard mask.
> 
I see what you mean, but cpupools are really a different thing, with its
own interface, etc. I'd rather try to implement what I described above
and being consistent with the current cpupool behavior, copying what it
happens already for hard affinity to how soft affinity is handled too
(as George was saying), at least for this series.

> > > What if the application makes a call to change the cpupool, without
> > > touching the affinities ?  Should the affinities be reset
> > > automatically ?
> > 
> > I think whatever happens for hard affinities right now should be carried on.
> 
> Maybe it is a bug that it doesn't do anything.  
>
Maybe, but that just mean that we can (should) fix that even outside
from this series, right?

> I think it depends how
> we expect people to use this.  
>
Indeed. :-D

> If a caller sets the hard affinities
> and then changes the cpupool, are they supposed to always then set the
> hard affinities again to a new suitable value ?
> 
Yes and no. :-) I'll provide some examples of what happens to try
clarifying the situation as soon as I get the chance.

Thanks for the review and the nice discussion. :-)
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel