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

Re: [Xen-users] Xen 3.1 terrible slowly on a laptop


  • To: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
  • From: carlopmart <carlopmart@xxxxxxxxx>
  • Date: Mon, 19 Nov 2007 17:07:11 +0100
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 19 Nov 2007 08:18:04 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Hwf5jx3RxYBSXRiYL6VT/+hjp1MoUIilvDEN1WZduUHdqR5IxrzaFb0imSbTej4JAxz9OySHAAGdrh8Y4XrQ4qrZ6pTV1alUF5Od7l7KE1B1HDGT3i5W3Ll7EMsG7maU2MFPx0OLUZeNO4rsMfZH4MRSEw1oFcsBhIfXm0WZcq4=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Nico Kadel-Garcia wrote:
carlopmart wrote:
Comment them out and just use the pygrub.

name = "RhelUpdates"
memory = "384"
maxmem = "384"
disk = [ 'tap:aio:/data/xenvmguests/rhel4updates/rhel4vol01.xvda,xvda,w' ]
vif = [ 'type=ieomu, mac=00:16:31:a5:67:13, bridge=natxenbr0' ]
vcpus = 1
on_reboot = 'restart'
on_crash = 'destroy'
sdl = 0
vnc = 1
vfb = [ 'type=vnc,vncunused=1' ]



I think that hdparm returns correcty parameters:
/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     = 16383/255/63, sectors = 156301488, start = 0

DMA it is activated, and this disk is IDE, I am not sure if I can activate 32 bits transfer using -c1 option on hdparm.
Almost any hard drive made this millennium can use 32-bit: the IDE defaults (more typically PATA now!) are set extremely, extremely low performance for backwards compatible reasons, and really should be updated. I once spent a long argument with a kernel developer about how "the kernel picks the higher performance default!" and had to walk him through the code that showed him, no, the kernel preserved what it was set to the lat time it was warm-rebooted. It you actually power off, it resets to to the lower settings and stays there until manually reset. It led to a huge performance improvement and the cost savings of buying a lot of big SCSI drives that had a serious kernel compatibility issue (due to this developer's insistence on backporting everything from new kernels instead of forward porting their modifications to a contemporary kernel: b-r-r-r-r!
If I don't put which kernel image needs to startup on guest system with kernel and ramdisk params, I can't start guest. Pygrub returns a lot errors about doesn't find a valid kernel image.
Ahh. Do you have the matching kernel installed in your guest domain, so that insmod can find them and install them? It definitely looks like you've not successfully loaded the boot loader in a way that grub can find it. Can you run "grub-install /dev/xvda1" from your working DomU environment?
 I will try to use a complete file image, and not sparse file ...

Cool. That's one source of performance issues to check.

ok, i have tried it using file image and not sparse file and with hdparm -c1 option and the results are the same: all is really slowly under dom0 ... I don't understand why...


OK. Hmm. What does "free" say, in your Dom0 and your DomU?


Buf .. I am really desesperated ... I don't understand nothing ... More things:

a) "free" command on dom0:
 [carlos@laptop ~]$ free
             total       used       free     shared    buffers     cached
Mem:        524288     330248     194040          0      12588     126084
-/+ buffers/cache:     191576     332712
Swap:      1012052          0    1012052

b) "free" command on domU:

[root@el4updates ~]# free
             total       used       free     shared    buffers     cached
Mem:        393348      58148     335200          0       4992      25428
-/+ buffers/cache:      27728     365620
Swap:       787176          0     787176

b) Using ntp with normal kernel on dom0 without xen enabled:

 ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-ntp1.belbone.be 195.13.23.6      2 u   86  128  377  124.718   23.650   0.892
*ns1.kamino.fr   193.52.184.106   2 u  120  128  377   80.813   -3.714   0.855
-ntp2.belbone.be 195.13.23.6      2 u   67  128  377   85.715  -12.910   0.547
+ns1.toponline.c 131.188.3.222    2 u  111  128  377   89.384   -1.763   0.987
 cctld.tix.ch    .STEP.          16 u    - 1024    0    0.000    0.000   0.000
+sake.ifi.unizh. 129.132.2.21     3 u  113  128  377   86.979    5.154   0.616
 audon.favey.ch  .STEP.          16 u    - 1024    0    0.000    0.000   0.000
 LOCAL(0)        .LOCL.          10 l   28   64  377    0.000    0.000   0.001

c) Using ntp with xen enabled kernel on dom0:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp2.hro.nl     192.87.36.4      2 u   50   64    7   64.496  19137.4 14865.8
 time2.ethz.ch   129.143.2.23     2 u   46   64    7   73.776  5671.86 12917.3
 130.226.232.145 192.36.133.25    2 u   51   64    7   87.601  5936.51 12252.0
 web04.mediainve 130.88.203.64    3 u   44   64    7   78.989  6726.28 12694.1
 LOCAL(0)        .LOCL.          10 l   48   64    7    0.000    0.000   0.001

 .. and of course, clock never synchronize ....

Why this differences??? Why this problems doesn't appears on a desktop machine or server???



--
CL Martinez
carlopmart {at} gmail {d0t} com

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


 


Rackspace

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