From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: [PATCH] Yield to VCPU hcall, spinlock yielding Date: Wed, 8 Jun 2005 14:17:56 -0500 Message-ID: <20050608191756.GD13586@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bryan S Rosenburg Cc: Ian Pratt , xen-devel@lists.xensource.com, hohnbaum@us.ibm.com, Orran Y Krieger , ryanh@us.ibm.com List-Id: xen-devel@lists.xenproject.org * Bryan Rosenburg [2005-06-08 13:40]: > "Ian Pratt" wrote on 06/08/2005 02:25:56 PM: > > > > The key point is that with > > > kernel-level preemption notification, VCPUs are always in > > > kernel mode when suspended, never in user mode. Application > > > state is always saved in Linux, not in Xen, and is available > > > to be resumed on another VCPU if Linux so chooses. > > > > In principle, but... > > > > Do you believe this is going to interact well with Linux's work stealing > > CPU migration? I haven't looked closely at the current code, but from > > Linux's scheduler's POV the de-scheduled (yielded) CPU looks like a > > perfectly healthy CPU, so there's no particular reason that another CPU > > would steal work from it (without hacking the algorithm, which I suppose > > we could do). Also, do you have to do something special in your yield > > routine to ensure that no real process is currently running on the > > yielded processor so that all processes on the run queue are available > > for stealing? > > > > Ian > > In our original posting, we proposed that the Linux interrupt handler for > preemption notifications would create (or unblock) a high-priority kernel > thread which would then yield back to the hypervisor. To Linux on other > CPUs, the de-scheduled CPU would appear to be busy running the > high-priority thread, and all real work that that CPU had been doing would > be eligible for stealing. > > I don't think that Ryan has yet implemented the high-priority thread part > of the proposal, but that's always been part of the plan. That is correct. I attempted to schedule some work on a particular cpu in the interrupt handler but I couldn't quite get it working. Currently, we are yielding in the interrupt handler which isn't what we proposed, but I had hoped that it was close enough to see the general effectiveness of the approach. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com