WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] VT is comically slow

To: "Rik van Riel" <riel@xxxxxxxxxx>, veillard@xxxxxxxxxx
Subject: RE: [Xen-devel] VT is comically slow
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Mon, 3 Jul 2006 16:43:19 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 03 Jul 2006 07:44:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44A9264E.7010803@xxxxxxxxxx>
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
Thread-index: Acaeq0u3xi0GCo/9RViOXaDxw6cTzwAAVwrw
Thread-topic: [Xen-devel] VT is comically slow
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Rik van Riel
> Sent: 03 July 2006 15:15
> To: veillard@xxxxxxxxxx
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] VT is comically slow
> 
> Daniel Veillard wrote:
> > On Mon, Jul 03, 2006 at 09:58:01AM +0100, Keir Fraser wrote:
> >> On 3 Jul 2006, at 09:48, Rik van Riel wrote:
> >>
> >>> Looking at it a bit more closely, it appears that postgresql
> >>> doing disk IO from inside a fully virtualized domain totally
> >>> kills the CPU.
> >>>
> >>> It gets so bad that a simple "dmesg" takes 10-20 seconds to start,
> >>> and after that it spews data maybe 7 or 8 lines every 
> other second.
> >>> Actually slower than serial console...
> >>>
> >>> This is totally unusable :(
> >> Might you be emulating PIO? That would certainly suck. The 
> device model 
> >> is supposed to support (virtual) DMA though.
> > 
> >   That's the first thing I though about but apparently the kernel
> > runs the IDE device in DMA mode if one believe the hdparm output in
> > that guest.
> 
> The information is conflicting...
> 
> While hdparm suggests DMA, the kernel profile has a suspicious
> amount of IDE in it.  Not sure what's going on...
> 
> # hdparm /dev/hda
> 
> /dev/hda:
>   multcount    = 16 (on)
>   IO_support   =  0 (default 16-bit)
>   unmaskirq    =  0 (off)
>   using_dma    =  1 (on)
>   keepsettings =  0 (off)
>   readonly     =  0 (off)
>   readahead    = 256 (on)
>   geometry     = 65535/16/63, sectors = 85899345920, start = 0
> 
> 
> # readprofile | sort -n | tail -20
> 148632 copy_user_generic                        498.7651
> 163787 copy_page                                731.1920
> 178136 __might_sleep                            1017.9200
> 178409 ide_intr                                 141.7069
> 277185 ide_outsl                                39597.8571
This ... 
> 324592 ide_execute_command                      772.8381
> 349538 sys_select                               300.0326
> 440036 unmap_vmas                               264.6037
> 478669 do_page_fault                            303.7240
> 585427 handle_IRQ_event                         6887.3765
> 1087766 ide_inw                                  120862.8889
And this... 
> 1115456 ide_do_request                           950.1329
> 2169643 do_wp_page                               1662.5617
> 2945913 ide_outbsync                             736478.2500
> 3888598 i8042_interrupt                          6480.9967
> 5892214 do_no_page                               2986.4237
> 11803041 thread_return                            20890.3381
> 13074317 __do_softirq                             80705.6605
> 81661803 poll_idle                                983877.1446
> 130083897 total                                     52.4560
> 
Are indications of IDE being used in PIO mode. Why this is, don't ask
me... 

Also, the read is 16-bit, making it twice as long as the read would be.
That's a "bug" in qemu, because it doesn't fall-back to two 16-bit
operations on reads, which it does for writes. [See default_ioport_readl
vs default_ioport_writel - the latter calls the writew twice, but the
former isn't doing the corresponding translation - don't know why this
is. I hacked it a while back to do two 16-bit reads, and it seemed to
work just fine for my miniature IDE-test application, but I don't know
if there's something else somewhere that breaks if you try to do that...


--
Mats
> 
> 
> -- 
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 



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