while testing laurents patch,
i have made the following interesting observation:
if i run a getpid-loop inside one uml, the other uml`s behaviour becomes
quite sluggish - this doesn`t seem to have a relation to laurents patch - i
just recognized this for the first time, because i never did getpid-loops
inside a uml. :)
ok - i would say:
yes - the system is heavily stressed - a busy uml makes the other one behave
sluggish, too .....but.....
why don`t i see any sluggish behaviour on the HOST itself ?
want to reproduce?
compile this little program and transfer it to your uml-root_fs`s
- let it run in one uml and the other uml(s) get sluggish - typing into the window and
issuing commands gives very slow response
- on the HOST there is no noticeable performance loss - typing,echoing, ls -la, df -kl,
... all seems normal and "feels" quite good.
- stop the getpid program and start another cpu/io hog (e.g. "while true;do find /;done)
inside one uml and compare that behaviour. other uml`s behave quite ok - the host, too.
no sluggish behaviour.
maybe this behaviour is quite normal (ok - a getpid-loop is a worst case scenario) - but
my system knowledge isn`t good enough, to explain , what`s going on here in detail.
is it, because the processing overhead of an uml is so high - so typing a char or issuing a
command "costs" so much more in an uml, so that we just can "see" the performance drop here,
and not on the host ?
----- Original Message -----
From: "Laurent Vivier" <LaurentVivier@...>
To: "roland" <for_spam@...>
Cc: "Jeff Dike" <jdike@...>; <user-mode-linux-devel@...>
Sent: Wednesday, May 19, 2004 8:17 PM
Subject: Re: [uml-devel] [PATCH] host context switch reduction
Le mer 19/05/2004 à 20:01, roland a écrit :
> Hi Laurent !
> Thanks a lot for your work :)
> but i have a question:
> old mail from jeff:
> >The patches below are from Laurent Vivier who didn't make them public. They
> >add a new feature to ptrace on the host which cuts down on the number of
> >context switches needed for a UML system call, plus makes UML use it
> so - if your patch adds a new feature for ptrace on the HOST - shouldn`t we need TWO patches for 2.6 ?
> One patch for uml and one patch for the host ?
> this one seems for uml only.
> some of us already run uml 2.6(.x) on a 2.6.(.x) host and put their focus on the "new kernel" (me too).
OK, as I didn't find skas patch for 2.6 I thought it didn't exist...
anyway I tried to port the 2.4 host sysemu patch to 2.6, find it
attached. I never tested it, or compiled it ! I have no system with 2.6
kernel, and the only I386 system I have is very, very, very noisy...
it's a good system only when it is switched off ;-) !
> since this would be the 2nd patch for the HOST (besides skas), would it make sense, to merge "skas" and "sysemu" into one common
> HOST-patch (if it has been tested and approved stable) ?
YES, I think... but Jeff is the boss ;-)
> ----- Original Message -----
> From: "Laurent Vivier" <LaurentVivier@...>
> To: "Jeff Dike" <jdike@...>
> Cc: "roland" <for_spam@...>; <user-mode-linux-devel@...>
> Sent: Wednesday, May 19, 2004 7:27 PM
> Subject: Re: [uml-devel] [PATCH] host context switch reduction
> as it is a plebiscite ;-), find attached the patch for UML 2.6.6 and
> measurements I made on my poor netserver.
> Le mar 18/05/2004 à 19:59, Jeff Dike a écrit :
> > On Tue, May 18, 2004 at 12:22:45AM +0200, roland wrote:
> > > the question is:
> > > is the "real world" performance benefit, uml get`s from this patch worth taking your time and is it implemented in a way, so
> > > uml maintainers are happy with that ?
> > The patch seems reasonable to me. I'd be happiest with Laurent pushing this
> > into mainline himself.
> > > i cannot really estimate, what performance benefits your patch brings to uml in detail, but what i have seen so far, this
> > > quite worth doing the work. reducing context switches by 1/3 is a LOT, imho - and reducing the execution time of the
> getpid-loop to
> > > nearly the half is quite impressive.
> > Yeah, but no real workloads do while(1) getpid();
> > The kernel build improvement is obviously smaller, but still worth having.
> > > are there any "con`s" that argue for that work _NOT_ being done ?
> > No. But testing, and happy reports to the appropriate mailing lists would
> > help.
> > Jeff
> > HP Netserver LH Pro bi-pro 200 MHz / 256 MB RAM
> > NATIF:
> > netserver:/usr/src# uname -a
> > Linux netserver 2.4.24-sysemu #4 SMP Tue Feb 17 16:43:11 CET 2004 i686 GNU/Linux
> > netserver:/usr/src# time ./getpid 1000000
> > real 0m1.763s
> > user 0m0.910s
> > sys 0m0.860s
> > real 0m1.759s
> > user 0m0.900s
> > sys 0m0.870s
> > real 0m1.759s
> > user 0m0.950s
> > sys 0m0.800s
> > UML with sysemu:
> > (none):~# uname -a
> > Linux (none) 2.6.6-1um #10 Wed May 19 12:54:37 CEST 2004 i686 unknown
> > (none):/mnt/usr/src# time ./getpid 1000000
> > real 1m1.508s
> > user 0m7.960s
> > sys 0m53.450s
> > real 1m1.881s
> > user 0m6.630s
> > sys 0m55.240s
> > real 1m1.920s
> > user 0m6.580s
> > sys 0m55.340s
> > UML w/o sysemu
> > real 1m32.833s
> > user 0m7.610s
> > sys 1m25.130s
> > real 1m32.921s
> > user 0m7.890s
> > sys 1m24.980s
> > real 1m33.493s
> > user 0m8.010s
> > sys 1m24.960s