fork/sh/hello microbenchmark performance in chroot

fork/sh/hello microbenchmark performance in chroot

[Shaya Potter]

I'm trying to play with our a homebrew version of lmbench's fork
benchmark which exec's sh to run a "hello world" program.  On normal
2.4.18 (UP 933mhz p3) it runs in about .2s  However, within a chrooted
environment I'm looking at 1s.

Anyone knows why this runs significantly slower within a chroot?

thanks,

shaya

Re: fork/sh/hello microbenchmark performance in chroot

[Shaya Potter]

in a followup, the only thing I can tell difference b/w the 2 runs
(under strace and inside and outside of the chroot) is that within the
chroot, after every fork() I see a SIGSTOP on the child.

anyone have any idea why this is happening?

On Thu, 2003-03-13 at 20:43, Shaya Potter wrote:
> I'm trying to play with our a homebrew version of lmbench's fork
> benchmark which exec's sh to run a "hello world" program.  On normal
> 2.4.18 (UP 933mhz p3) it runs in about .2s  However, within a chrooted
> environment I'm looking at 1s.
> 
> Anyone knows why this runs significantly slower within a chroot?
> 
> thanks,
> 
> shaya
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: fork/sh/hello microbenchmark performance in chroot

[Shaya Potter]

and a little more followup.  The chroot is basically a machine's fs's
mounted over nfs over an ipsec tunnel

/chroot/"filesystems"

when I run it /chroot/tmp/benchmark/forksh, I get .2s

but when I chroot into the /chroot tree and run /tmp/benchmark/forksh I
get 1s.

If I make the chroot tree just composed of mount -o bind'd fs from the
host machine, I don't see the slow down.

so to recap

plain linux, local filesystems - it's fine
plain linux, nfs over ipsec filesystems - it's fine
chrooted linux, local filesystems - it's fine
chrooted linux, nfs over ipsec filesystems - it's very slow.

thanks,

shaya

On Thu, 2003-03-13 at 20:54, Shaya Potter wrote:
> in a followup, the only thing I can tell difference b/w the 2 runs
> (under strace and inside and outside of the chroot) is that within the
> chroot, after every fork() I see a SIGSTOP on the child.
> 
> anyone have any idea why this is happening?
> 
> On Thu, 2003-03-13 at 20:43, Shaya Potter wrote:
> > I'm trying to play with our a homebrew version of lmbench's fork
> > benchmark which exec's sh to run a "hello world" program.  On normal
> > 2.4.18 (UP 933mhz p3) it runs in about .2s  However, within a chrooted
> > environment I'm looking at 1s.
> > 
> > Anyone knows why this runs significantly slower within a chroot?
> > 
> > thanks,
> > 
> > shaya
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: fork/sh/hello microbenchmark performance in chroot

[Shaya Potter]

final followup I think.

the sigstop I see after every fork from strace is

PID --- SIGSTOP (Stopped (signal)) @ 0 (0) ---

don't know what the @ 0 (0) means

On Thu, 2003-03-13 at 21:03, Shaya Potter wrote:
> and a little more followup.  The chroot is basically a machine's fs's
> mounted over nfs over an ipsec tunnel
> 
> /chroot/"filesystems"
> 
> when I run it /chroot/tmp/benchmark/forksh, I get .2s
> 
> but when I chroot into the /chroot tree and run /tmp/benchmark/forksh I
> get 1s.
> 
> If I make the chroot tree just composed of mount -o bind'd fs from the
> host machine, I don't see the slow down.
> 
> so to recap
> 
> plain linux, local filesystems - it's fine
> plain linux, nfs over ipsec filesystems - it's fine
> chrooted linux, local filesystems - it's fine
> chrooted linux, nfs over ipsec filesystems - it's very slow.
> 
> thanks,
> 
> shaya
> 
> On Thu, 2003-03-13 at 20:54, Shaya Potter wrote:
> > in a followup, the only thing I can tell difference b/w the 2 runs
> > (under strace and inside and outside of the chroot) is that within the
> > chroot, after every fork() I see a SIGSTOP on the child.
> > 
> > anyone have any idea why this is happening?
> > 
> > On Thu, 2003-03-13 at 20:43, Shaya Potter wrote:
> > > I'm trying to play with our a homebrew version of lmbench's fork
> > > benchmark which exec's sh to run a "hello world" program.  On normal
> > > 2.4.18 (UP 933mhz p3) it runs in about .2s  However, within a chrooted
> > > environment I'm looking at 1s.
> > > 
> > > Anyone knows why this runs significantly slower within a chroot?
> > > 
> > > thanks,
> > > 
> > > shaya
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: fork/sh/hello microbenchmark performance in chroot

[Pavel Machek]

Hi!

> when I run it /chroot/tmp/benchmark/forksh, I get .2s
> 
> but when I chroot into the /chroot tree and run /tmp/benchmark/forksh I
> get 1s.

And if you force forksh to use libc from
chroot?
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...