From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [Patch 2 of 2]: PV-domain SMP performance Linux-part Date: Fri, 19 Dec 2008 11:42:15 +0100 Message-ID: <494B7A87.10801@fujitsu-siemens.com> References: <494B5769.6030206@fujitsu-siemens.com> <494B7892.76E4.0078.0@novell.com> <494B721D.6000003@fujitsu-siemens.com> <494B8722.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <494B8722.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: >>>> Juergen Gross 19.12.08 11:06 >>> >> Regarding handling this in Xen only: not to deschedule a vcpu in case of >> interrupts disabled is easy, but how would you deschedule it after interrupts >> are allowed again? > > It's all the same as with the newly added flag of yours - it requires cooperation > from the guest (plus the forced de-schedule if it fails to do so). It's just that > you don't need to set two flags when disabling interrupts, that second flag > would only be needed when you want to avoid being de-scheduled for > reasons other than event delivery being disabled. I just wanted to be independent from the event mechanism. I'm fine with merging the two features, but it would be more limiting than necessary. It's like disabling IRQs and avoiding preemption of a thread: you can avoid preemption by disabling IRQs, but this is not the best way to do it... Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: juergen.gross@fujitsu-siemens.com Otto-Hahn-Ring 6 Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html