Re: [Xen-devel] [PATCH RESEND 05/12] xen: numa-sched: make space for per-vcpu node-affinity

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On mer, 2013-11-06 at 15:14 +0000, Jan Beulich wrote:
> >>> On 06.11.13 at 15:56, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:

> > I guess I was assuming that a vcpu's soft affinity would always be 
> > considered a subset of its hard affinity and the cpus in its cpupool.
> 
Well, we're doing all this talking with the specific goal or disentangle
soft from har from memory affinities, aren't we? However, yes, for both
logical and implementation reasons, a domain that lives in a pool should
not have either soft or hard affinity to any pcpu which is outside of
the pool.

For hard affinities, not so much. Meaning that is it possible (it was
possible in this series, and I think it should remain possible in its
new incarnation) to have completely disjoint sets of pcpus as hard an
soft affinities, at least at the hypervisor level.

Then, of course, high in the toolstack we can come up with proper
policing, but that's a different issue. Or are you (George) saying that
if domain A has soft affinity to pcpus 0-15, setting its hard affinity
to 0-7 should affect the soft atinity (an constraint it within that
range) too?

I'm almost sure we had a similar discussion in another thread, and it
was you tha argued that we should not introduce these kind of
dependencies, when the user changes parameter X and this silently result
in Y changing too...

> For CPU pools I agree, but didn't we mean hard affinity to control
> memory allocation, and soft affinity scheduling decisions (in which
> case there's no strict ordering between the two)? If not, I guess I'd
> need a brief but clear definition what "soft" and "hard" are supposed
> to represent...
> 
Well, let me try. Both hard and soft affinity is all about scheduling,
with the following meaning:
 - hard: the *allowed* pcpus
 - soft: the *preferred* pcpus
If there are no free *preferred* pcpus, as well as if the soft affinity
mask is empty or has empty intersection with the hard one, a pcpu from
the *allowed* one is picked up by the scheduler.

Memory allocation is controlled by (let's call i like that) node
affinity. There will be specific (hyper)calls to set it explicitly, but
the point here is, if none of those is invoked, how should it look like?

My opinion is that, doing as you said, and have it be based on hard
affinities makes things easier and quicker to implement, and guarantees
the most consistent behavior wrt the current one. Thus, although, I know
we don't care much about backward compatibility at this level, I'd go
for it.

Thanks and Regards,
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: signature.asc
Description: This is a digitally signed message part

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