Squashfs performance (3.3 vs 4.0 in mainline)

Squashfs performance (3.3 vs 4.0 in mainline)

[Simon Kagstrom]

Hi!

I'm running 2.6.31 on a slow ARM platform and using squashfs 4.0 as
shipped with the kernel. It's a Sharp LH79524, so the architecture
itself isn't mainlined yet.

Squashfs works well, but I've noted a performance regression compared
to the out-of-tree squashfs 3.3 which we ran on 2.6.23. The new kernel
is faster until the squashfs root filesystem is mounted, but after that
it goes downhill. Especially mounting takes a lot more time with the
new:

2.6.23 / 3.3:

  [ 0.01]: [    1.250000] RAMDISK: squashfs filesystem found at block 0
  [ 0.01]: [    1.260000] RAMDISK: Loading 2156KiB [1 disk] into ram disk... done.
  [ 1.39]: [    2.650000] VFS: Mounted root (squashfs filesystem) readonly.
  [ 0.01]: [    2.660000] Freeing init memory: 80K

2.6.31 / 4.0:

  [ 0.00]: [    1.080000] RAMDISK: squashfs filesystem found at block 0
  [ 0.01]: [    1.090000] RAMDISK: Loading 2372KiB [1 disk] into ram disk... done.
  [ 2.79]: [    3.880000] VFS: Mounted root (squashfs filesystem) readonly on device 1:0.
  [ 0.01]: [    3.890000] Freeing init memory: 80K

(The first column is the time difference compared to last timestamp).
Are there any general changes which could have caused this difference?


I've tried with various mksquashfs options, and -noI makes it somewhat
faster (and larger), but not near the old version.

// Simon

Re: Squashfs performance (3.3 vs 4.0 in mainline)

[Phillip Lougher]

On Thu, Dec 10, 2009 at 2:02 PM, Simon Kagstrom
<simon.kagstrom@netinsight.net> wrote:

> Squashfs works well, but I've noted a performance regression compared
> to the out-of-tree squashfs 3.3 which we ran on 2.6.23. The new kernel
> is faster until the squashfs root filesystem is mounted, but after that
> it goes downhill. Especially mounting takes a lot more time with the
> new:
> (The first column is the time difference compared to last timestamp).
> Are there any general changes which could have caused this difference?
>

There's nothing which should have caused such a slow-down in Squashfs.
 Unfortunately, you're comparing Squashfs 3.3 on 2.6.23, with Squashfs
4.0 on 2.6.31, there's a huge amount of kernel differences between the
two.  Anything broken in your 2.6.31 kernel (caching, memory handling,
interrupts etc.) could be the underlying cause.

Personally, I would try and isolate the problem more before blaming
Squashfs.  A couple of things which you should try:

1. Try a different filesystem, i.e. cramfs or ext2, on both 2.6.23 and
2.6.31.  Do you get the same slowdown?  Preferable to use cramfs, as
this has similar compute intensive decompression overhead.

2. Enable tracing in Squashfs and send the output.  Squashfs 3.3/4.0
should behave the same way.  This will pinpoint such issues.

3. Do some compute intensive, and memory/IO intensive application
benchmarking, on both your 2.6.23 and 2.6.31 kernels.

4. Test Squashfs 3.3 in your 2.6.31 kernel.  Do you get the same
slowdown?  If the above tests still tend to show Squashfs 4.0 is the
issue, I'm prepared to produce a Squashfs 3.3 patch for 2.6.31 for
you.

>
> I've tried with various mksquashfs options, and -noI makes it somewhat
> faster (and larger), but not near the old version.
>

OK.  This shows less compression makes it go faster.  If you have a
slow CPU this is to be expected, and would happen with or without any
underlying problems somewhere.

Phillip