[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>
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
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?
> 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.
Xen-devel mailing list