qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a V


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2)
Date: Thu, 02 Dec 2010 17:33:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.6

On 12/02/2010 05:27 PM, Srivatsa Vaddagiri wrote:
>  >Even that would require some precaution in directed yield to ensure that it
>  >doesn't unduly inflate vruntime of target, hurting fairness for other 
guests on
>  >same cpu as target (example guest code that can lead to this situation
>  >below):
>  >
>  >vcpu0:                                vcpu1:
>  >
>  >                              spinlock(A);
>  >
>  >spinlock(A);
>  >
>  >                              while(1)
>  >                              ;
>  >
>  >                              spin_unlock(A);
>
>  directed yield should preserve the invariant that sum(vruntime) does
>  not change.

Hmm don't think I understand this invariant sum() part. Lets take a simple
example as below:


p0      ->  A0 B0 A1

p1      ->  B1 C0 C1

A/B/C are VMs and A0 etc are virtual cpus. p0/1 are physical cpus

Let's say A0/A1 hit AB-BA spin-deadlock (which one can write in userspace
delibrately). When A0 spins and exits (due to PLE) what does its directed yield
do? Going by your statement, it can put target before current, leading to
perhaps this arrangement in runqueue:

p0      ->  A1 B0 A0

Now A1 spins and wants to do a directed yield back to A0, leading to :

p0      ->  A0 B0 A1

This can go back and forth, starving B0 (iow leading to some sort of DoS
attack).

Where does the "invariant sum" part of directed yield kick in to avoid such
nastiness?

A0 and A1's vruntime will keep growing, eventually B will become leftmost and become runnable (assuming leftmost == min vruntime, not sure what the terminology is).

--
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]