This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
From: Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>
Date: Thu, 9 Jun 2005 08:37:50 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, hohnbaum@xxxxxxxxxx, Orran Y Krieger <okrieg@xxxxxxxxxx>, habanero@xxxxxxxxxx, ryanh@xxxxxxxxxx
Delivery-date: Thu, 09 Jun 2005 12:36:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D282138@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> wrote on 06/08/2005 05:29:21 PM:

> We might be able to come up with a cheaper hack for doing this. The
> notifaction scheme is already on the expensive side, and adding two
> extra passes through the scheduler could totally doom it.

I agree that whether we can tolerate the cost of preemption notification interrupts is still very much an open question.  I doubt that the additional costs of unblocking and blocking a kernel thread will be decisive.

I don't view the high-priority kernel thread idea as a "hack".  In conjunction with CONFIG_PREEMPT, it is a straight-forward solution to a real problem:  From the notification interrupt handler, how do you get the kernel to yield as quickly as possible but only at such time as no kernel locks are held?  A newly-unblocked high-priority thread will run at exactly the right time, with no new hacking on Linux locking or scheduling code.

- Bryan
Xen-devel mailing list