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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
> > > 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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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...