Re: Questions / Comments about hard / soft affinity in Credit 2

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

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

You know that you sent 3 copies of this message in a time span of 20
minutes, don't you? :-)

That is not ideal for mailing list like xen-devel (but I think that is
valid for mailing lists in general).

Anyway... let me sort out a couple of stuff, and then I'll reply to the
technical arguments.

Dario

On lun, 2013-12-09 at 22:08 -1000, Justin Weaver wrote:
> 
> Hello,
> 
> On Sat, Nov 30, 2013 at 10:18 PM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
>         I'll have to re-look at the details of credit2 about load
>         balance and
>         migration between CPUs/runqueues but it looks like we need to
>         have
>         something allowing us to honour pinning/affinity _within_ the
>         same
>         runqueue, anyway, don't we? I mean, even if you implement
>         per-L2
>         runqueues, that would still span more than one CPU, and the
>         user may
>         well want to pin a vCPU to only one (or in general a subset)
>         of them.
> 
> 
> Yes, I agree. Just looking for some feedback before I attempt a patch.
> Some of the functions I think need updating for hard/soft affinity...
> 
> 
> runq_candidate needs to be updated. It decides which vcpu from the run
> queue to run next on a given pcpu. Currently it only takes credit into
> account. Considering hard affinity should be simple enough. For soft,
> what if it first looked through the run queue in credit order at only
> vcpus that prefer to run on the given processor and had a certain
> amount of credit, and if none were found it then considered the whole
> run queue considering only hard affinity and credit?
> 
> 
> runq_assign assumes that the run queue associated with vcpu->processor
> is OK for vcpu to run on. If considering affinity, I'm not sure if
> that can be assumed. I probably need to dig further into schedule.c to
> see where vcpu->processor is being assigned initially. Anyway, with
> only one run queue this doesn't matter for now.
> 
> 
> choose_cpu / migrate will need to be updated, but currently migrate
> never gets called because there's only one run queue.
> 
> 
> Please let me know what you think.
> 
> 
> Thanks,
> Justin
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
<<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