Xen 3.0.4...

[Boudreau Luc]

Hi !

 

Correct me if I'm wrong, but considering this :

 

-          FC6 ships with Xen 3.0.3 with xen-kernel version 2.6.20

-          Xen 3.0.3 has a serious performance bug (see
http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00487.html
)

-          This bug is fixed in Xen 3.0.4

-          Xen 3.0.4 ships with xen-kernel 2.6.16

 

Is it possible to install both a recent kernel version (>2.6.18) AND Xen
3.0.4 and still take advantage of the FC6 update mechanism ? Can I
install the xen kernel shipped with FC6 and regularely updated through
the update system, AND have a manual installation of Xen 3.0.4 ??

 

Luc

[Daniel P. Berrange]

On Wed, Apr 25, 2007 at 03:31:49PM -0400, Boudreau Luc wrote:
>  Correct me if I'm wrong, but considering this :
>  
>  -          FC6 ships with Xen 3.0.3 with xen-kernel version 2.6.20
>  
>  -          Xen 3.0.3 has a serious performance bug (see
>  http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00487.html
>  )
>  
>  -          This bug is fixed in Xen 3.0.4 
No it isn't. The performance bug is actually at least x2 worse in Xen 3.0.4

http://lists.xensource.com/archives/html/xen-devel/2007-04/msg00663.html


If you want immediate relief from xenstore performance problems in 3.0.3, 
the quick *hack* is to add this in /etc/init.d/xend

        if [ -d /dev/shm ]; then
           if [ ! -d /dev/shm/xenstored ]; then
             mkdir /dev/shm/xenstored
             chcon system_u:object_r:xenstored_var_lib_t /dev/shm/xenstored/
             mount --bind /dev/shm/xenstored /var/lib/xenstored
           fi
        fi

Immediately after the 'modprobe netloop' line in the start() function.
This stops xenstored I/O hitting your disk, by moving it into a ramdisk.
There's no need to keep xenstored state around between reboots so this
is a reasonably safe hack. I'm experimenting with more long term fixes.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Boudreau Luc]

Wow, thanks for the quick answer AND the solution. Frankly, I'm impressed.

Nothing to report on this hack then ? No side effects ? (except the fact that the state is
not persisted, which is irrelevent anyways...)

Luc


-----Message d'origine-----
De : Daniel P. Berrange [mailto:[e-mail]] 
Envoyé : 25 avril 2007 15:38
À : Boudreau Luc
Cc : fedora-xen(a)redhat.com
Objet : Re: [Fedora-xen] Xen 3.0.4...

On Wed, Apr 25, 2007 at 03:31:49PM -0400, Boudreau Luc wrote:
>  Correct me if I'm wrong, but considering this :
>  
>  -          FC6 ships with Xen 3.0.3 with xen-kernel version 2.6.20
>  
>  -          Xen 3.0.3 has a serious performance bug (see
>  http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00487.html
>  )
>  
>  -          This bug is fixed in Xen 3.0.4 
No it isn't. The performance bug is actually at least x2 worse in Xen 3.0.4

http://lists.xensource.com/archives/html/xen-devel/2007-04/msg00663.html


If you want immediate relief from xenstore performance problems in 3.0.3, 
the quick *hack* is to add this in /etc/init.d/xend

        if [ -d /dev/shm ]; then
           if [ ! -d /dev/shm/xenstored ]; then
             mkdir /dev/shm/xenstored
             chcon system_u:object_r:xenstored_var_lib_t /dev/shm/xenstored/
             mount --bind /dev/shm/xenstored /var/lib/xenstored
           fi
        fi

Immediately after the 'modprobe netloop' line in the start() function.
This stops xenstored I/O hitting your disk, by moving it into a ramdisk.
There's no need to keep xenstored state around between reboots so this
is a reasonably safe hack. I'm experimenting with more long term fixes.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Daniel P. Berrange]

On Wed, Apr 25, 2007 at 03:42:22PM -0400, Boudreau Luc wrote:
>  
>  Wow, thanks for the quick answer AND the solution. Frankly, I'm 
>  impressed.
>  
>  Nothing to report on this hack then ? No side effects ? (except 
>  the fact that the state is not persisted, which is irrelevent anyways...) 
The hack isn't a complete solution - it merely lowers the performance
hit to some degree by removing disk I/O. There is still considerable CPU 
usage in xenstored simply by copying data to/from tmpfs RAM disk. In my tests
using tmpfs reduces CPU usage from 60% to 30%. The real fix in XenD
ought to reduce xenstored CPU usage to < 1 %

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|