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


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

To: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
Subject: Re: [Xen-users] Xen 3.1 terrible slowly on a laptop
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=DmtMyC7SlQmwk+D2DjYzbuUyPbwZBDXFrqykCjNyB2I=; b=lkXfN7nZjT0bkrc8gSAYx8m4c98xM7aUE7viVxDJswaNrfb70o1JLUaLMPJR9iZiNH3uWc+OME7oMvYe34yx7vszDJ90hZiRsftGAVKZ+hIZIvj23fJTEEtVQb6URSUXBkLjrUcMK55XN26MzsnLQloeMbv1sg1sExRWzmuyWe8=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4740B601.7080205@xxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <473F7439.5090401@xxxxxxxxx> <473F86C8.2050103@xxxxxxxxx> <473FE9F6.4090307@xxxxxxxxx> <473FF932.6060205@xxxxxxxxx> <47403344.2060003@xxxxxxxxx> <47403D48.2070508@xxxxxxxxx> <47408F60.6010600@xxxxxxxxx> <47409541.40402@xxxxxxxxx> <4740971C.3050701@xxxxxxxxx> <4740B601.7080205@xxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20071031)
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:
 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