[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 10:37:27 +0100
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 19 Nov 2007 01:38:23 -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=n9Oi0qQqmY8y/g/jIy4Uns5lUuXdq5cWi5NZ46vwRKxP812PeN6RRK2Xn4CaZf4/O8VyqIcoeiKV9bzB7SLTOgbNWECUA1vW1FnRCDcFnilKRL0XkYLvJbQ59ifvoCAsoh95rGv7UQ9r7FbnW1AkVGseG1vlOMF/vJ6Vmcu2JM8=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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



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