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

[carlopmart <carlopmart@xxxxxxxxx>]

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