OpenVZ Forum


Home » Mailing lists » Devel » Container Test Campaign
Re: [Vserver] Re: Container Test Campaign [message #4517 is a reply to message #4512] Thu, 13 July 2006 02:07 Go to previous message
Herbert Poetzl is currently offline  Herbert Poetzl
Messages: 239
Registered: February 2006
Senior Member
On Wed, Jul 12, 2006 at 06:31:25PM +0200, Clément Calmels wrote:
> Le mardi 11 juillet 2006 à 13:18 +0400, Kirill Korotaev a écrit :
> > > Some updates on
> > > http://lxc.sourceforge.net/bench/
> > >
> > > New design, results of the stable version of openvz added, clearer
> > > figures.
> > >
> >
> > 1. are 2.6.16 OVZ results still for CFQ disk scheduler?
>
> This tests are currently in progress... for the moment, it seems that
> the anticipatory io scheduler improves performance a lot.
>
> > 2. there is definetely something unclean in your testing as
> > vserver and MCR makes dbench faster than vanilla :))

that's not really unusual ...

> Couldn't some test be faster inside a container than with a Vanilla?

yes, they definitely can, and some very specific ones
are constantly faster regardless of how many tests
and/or setups you have ...

> For example if I want to dump all files in /proc, obviously inside a
> light container it will be faster because /proc visibility is limited
> to the container session. Just to be clear:
>
> r3-21:~ # find /proc/ | wc -l
> 4213
> r3-21:~ # mcr-execute -j1 -- find /proc/ | wc -l
> 729
>
> I'm not sure and I'm still investigating. I'm now adding Oprofile to all
> tests to have more information. If you know technical reasons that imply
> different results, let me know. Help welcome!

yes, the 'isolation' used in Linux-VServer already
gave that 'at first glance' strange behaviour that
some tests are 'faster' inside a guest than on the
real/vanilla system, so for us it is not really new
but probably it is still confusing, here are a few
reasons _why_ some tests are better than the 'original'

- structures inside the kernel change, relations
between certain structures change too, some of
those changes cause 'better' behaviour, just
because cache usage or memory placement is different

- many checks walk huge lists to find a socket or
process or whatever, some of them use hashes to
speed up the search, the lightweight guests often
provide faster access to 'related' structures

- scheduler and memory management are tricky beasts
sometimes it 'just happens' that certain operations
and/or sequences are faster than other, although
they give the same result

HTC,
Herbert

> --
> Clément Calmels <clement.calmels@fr.ibm.com>
>
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [PATCH] fdset's leakage
Next Topic: [andrex@alumni.utexas.net: Bug#378045: vzctl: /etc/init.d/vz gives up too easily, doesn't tell me wh
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Mon Jul 07 03:46:34 GMT 2025

Total time taken to generate the page: 0.03827 seconds
Powered by FUDforum Powered by Virtuozzo Containers