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

[Xen-devel] Re: Need help with fixing the Xen waitqueue feature


  • To: olaf@xxxxxxxxx
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Tue, 8 Nov 2011 19:37:59 -0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 08 Nov 2011 19:40:29 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=cD02bepAOpRgq1jKtI3n7/3H8j5mpcJG3+6de7e53Fbr vK8BoMTJa70uCIiV+fWoG+qNJoAagq/HA4P4svUPR74JKDtS++h7gXDo/EIPoBVc baxpi03Wql+fNgcDzcF8gAJdhmsZp7PPgINJFdyT5JxhzzupMQP2G7xMSFfuRpg=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Olaf,
are waitqueue's on the mem-event ring meant to be the way to deal with
ring exhaustion? i.e. is this meant to go beyond a testing vehicle for
waitqueue's?

With the pager itself generating events, and foreign mappings generating
events, you'll end up putting dom0 vcpu's in a waitqueue. This will
basically deadlock the host.

Am I missing something here?
Andres

> Date: Tue, 8 Nov 2011 22:20:24 +0100
> From: Olaf Hering <olaf@xxxxxxxxx>
> Subject: [Xen-devel] Need help with fixing the Xen waitqueue feature
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Message-ID: <20111108212024.GA5276@xxxxxxxxx>
> Content-Type: text/plain; charset=utf-8
>
>
> The patch 'mem_event: use wait queue when ring is full' I just sent out
> makes use of the waitqueue feature. There are two issues I get with the
> change applied:
>
> I think I got the logic right, and in my testing vcpu->pause_count drops
> to zero in p2m_mem_paging_resume(). But for some reason the vcpu does
> not make progress after the first wakeup. In my debugging there is one
> wakeup, the ring is still full, but further wakeups dont happen.
> The fully decoded xentrace output may provide some hints about the
> underlying issue. But its hard to get due to the second issue.
>
> Another thing is that sometimes the host suddenly reboots without any
> message. I think the reason for this is that a vcpu whose stack was put
> aside and that was later resumed may find itself on another physical
> cpu. And if that happens, wouldnt that invalidate some of the local
> variables back in the callchain? If some of them point to the old
> physical cpu, how could this be fixed? Perhaps a few "volatiles" are
> needed in some places.
>
> I will check wether pinning the guests vcpus to physical cpus actually
> avoids the sudden reboots.
>
> Olaf
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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