Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.03.16 at 17:01, <george.dunlap@xxxxxxxxxx> wrote:
> On 09/03/16 13:39, Jan Beulich wrote:
>>>>> On 08.03.16 at 19:38, <george.dunlap@xxxxxxxxxx> wrote:
>>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>>> about with "Something bad may happen" being difficult to work with.
>>> Rather than you spelling out exactly the situation which you think may
>>> happen, (which I could then either accept or refute on its merits) *I*
>>> am now spending a lot of time and effort trying to imagine what
>>> situations you may be talking about and then refuting them myself.
>> 
>> I thought I was precise enough (without going into too much detail),
>> but looks like I wasn't.
>> 
>> 1) vCPU1 blocks on pCPU1 (indefinitely for the purpose here)
>> 2) vCPU2 gets migrated to pCPU1 and blocks (indefinitely ...)
>> ...
>> n) vCPUn gets migrated to pCPU1 and blocks (indefinitely ...)
>> n+1) a PI wakeup interrupt arrives on pCPU1
>> 
>> In this consideration it doesn't matter whether the vCPU-s are all
>> from the same or different VMs. The sole requirement is that they
>> must satisfy the condition(s) to be put on the blocking list.
> 
> Right -- so here's one of our differing assumptions.  In my experience
> there is no such thing as a truly idle vcpu: they always wake up at
> least occasionally (usually a few times a second) for some reason or
> other.  (Which is why I talked about the load of each idle vcpu being
> less than 0.02%.)  So I was assuming that the vcpu would be stolen
> during one of the 0.02% time it was running.
> 
> But let's suppose that's not the case -- the chances of something like
> you're talking about happening are astronomically small.
> [...]
> This is just incredibly far-fetched.  By the time this happens to
> someone they will already have been struck by lightning 50 times and won
> the billon dollar Powerball jackpot twice; at that point they won't care.

I agree with all of this, and especially this last paragraph was
really fun to read - except for the (implied) conclusion you want
me to draw. Nevertheless many of the XSAs we issue are about
things that may not arise in practice, unless someone
(maliciously?) arranges for it.

> Right -- well having a mechanism to limit the total number of pi-capable
> vcpus assigned to a single pcpu would be something we could consider too
> -- once we have an idea what kind of number that might be.

As said before, I don't think we need any fixed number here. What
we need is a criteria of how much of an imbalance we're willing to
tolerate. With the assumption that the total load the admin places
on a system is reasonable, a reasonably balanced distribution will
also result in reasonable lookup performance. For example we
could require that the number of vCPU-s on any pCPU list is no
more than double or triple the ratio total-vCPU-s / total-pCPU-s
(with that ratio rounded upwards to an integer, and with the
number on list perhaps always allowed to reach some reasonably
small value - say 16 - even if that exceeds said ratio).

Jan


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