RE: [Xen-devel] VT is comically slow

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----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