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

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2





On 24/01/17 13:19, Dario Faggioli wrote:
On Tue, 2017-01-24 at 13:04 +0000, Julien Grall wrote:
On 24/01/17 12:53, Dario Faggioli wrote:
Do you have a script and/or some more info for letting me try to
reproduce it (e.g., you say some otf the vCPUs are pinned, which
one?
etc)?

That was mentioned in my first e-mail :). My configuration is:
        - ARM platform with 6 cores
        - staging Xen with credit2 enabled by default
        - DOM0 using 2 pinned vCPUs
        - Guest using 2 vCPUs (not pinned)

Yeah, but some of the details were either missing, or not clear to
me... Sorry for bothering and thanks for re-stating this here. :-)

How are Dom0 vCPUs pinned, exclusively (i.e., there are 2 pCPUs on
which _only_ Dom0 and _no_ DomU can run)?

I have dom0_vcpu_pins on Xen command line option (so I guess only pinned?), no further configuration for DOM0.


The script is really simple:

for i in `seq 1 10`; do
        sudo xl create ~/works/guest/guest.cfg;
        sudo xl destroy guest;
done

Ok.

I'm a bit curious about why you're saying this is being exposed by
using Credit2.

It is been exposed by Credit2 because compared to Credit1 there is
no
interrupt traffic made by the scheduler.

So, when you say "no interrupt traffic", do you perhaps mean that
SCHEDULE_SOFTIRQ is rarely (never!) raised for idle pCPUs? Or are you
really talking about actual interrupts (either inter-processor or not)?

I am talking about actual physical interrupts. The traffic is reduced to none with credit2 on idle pCPU.

Cheers,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.