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: Orran Y Krieger <okrieg@xxxxxxxxxx>
Date: Thu, 9 Jun 2005 14:13:43 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>, hohnbaum@xxxxxxxxxx, habanero@xxxxxxxxxx, ryanh@xxxxxxxxxx
Delivery-date: Thu, 09 Jun 2005 18:12:54 +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:
> > I'd view your "cpu_power" proposal as orthogonal to (or
> > perhaps complementary to) our ideas on preemption
> > notification.  It's aimed more at load-balancing and fair
> > scheduling than specifically at the problems that arise with
> > the preemption of lock holders.  On the apparent CPU speed
> > issue, does Linux account in any way for different interrupt
> > loads on different processors?  Is a program just out of luck
> > if it happens to get scheduled on a processor with heavy
> > interrupt traffic, or will Linux notice that it's not making
> > the same progress as its peers and shuffle things around?  It
> > seems that your cpu_power proposal might have something to
> > contribute here.
> I don't see it as orthogonal -- I think something like it is needed to
> make the notification scheme result in any benefit, otherwise no work
> will get migrated from the de-scheduled CPU.

I don't get it. If an application lock is important, and all the app threads block on it except the one of the preempted processor, and the preempted processor has two threads on it (the high priority kernel and the app that was preempted), then we have one (or more) idle processors and one processor with two threads.  Hopefully the scheduler is smart enough to move the preempted thread over. So, the base scheme should result in processors from staying idle....  A scheme like described above would be great, but without any changes we have a scheme that keeps processors from going idle I think.  

> I'm just not sure how easy it will be to add into the rebalance
> function.
> Ian  
Xen-devel mailing list