[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch 2 of 2]: PV-domain SMP performance Linux-part


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 19 Dec 2008 11:06:21 +0100
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 19 Dec 2008 02:06:48 -0800
  • Domainkey-signature: s=s768; d=fujitsu-siemens.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=DJf0tPGrgGJwpCNaVfW7uUF0hu6en7nNzN6MVwsX7Wc7CL5sAD8ssujM 2aliB8Vs230xrei8vRgOYs5czkfIL46YFWAOhxIXzv+2lvNGxBqtNaiX1 h0TDSdG18u/Xas1;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Jan Beulich wrote:
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 19.12.08 10:10 >>>
>> I haven't seen any win on any real world setup. So I remain unconvinced, and
>> it'll need more than you alone championing the patch to get it in. There
>> have been no other general comments so far (Jan's have been about specific
>> details).
> 
> I think I'd generally welcome a change like this, but I'm not certain how far
> I feel convinced that the submission meets one very basic criteria:
> avoidance of mis-use of the feature by a domain (simply stating that a vCPU
> will be de-scheduled after 1ms anyway doesn't seem sufficient to me). This
> might need to include ways to differentiate between Dom0/DomU and/or
> CPU- vs IO-bound vCPU-s.

It would be possible to sum up the mis-usages. The extra 1 msec could be
allowed only if the total consumed time of the vcpu is at least 1000 times
the extra time spent so far. Or we could allow it only if no mis-usage had
been recorded in the last second.

> 
> Beyond that, it seems questionable that tying this to event delivery being
> disabled on the vCPU is very useful - Xen could do this on its own, without
> needing a second flag. Having an extra flag really seems useful only when
> one can set it while holding spin locks, which at least the Linux part of the
> patch doesn't seem to aim at.

My first test was not limited to the irq disabling. I tried to tie it to the
preemption_count of the current thread by adding special functions for
manipulating the preemption_count. I found this approach was to complicated
for a first test as I obviously missed some details (the resulting system
did work, but was much slower as before).
I think it would be interesting to spend some more time to tune this, but I
wanted to get some feedback first. And, to be honest, I don't think I am
the right person to do this, as I'm really no Linux scheduling specialist :-)

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?


Juergen

-- 
Juergen Gross                             Principal Developer
IP SW OS6                      Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers         e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.