Re: Q. cache in squashfs?

["J. R. Okajima" <hooanon05@yahoo.co.jp>]

Phillip Lougher:
> You can determine which blocks are being repeatedly decompressed by
> printing out the value of cache->name in squashfs_cache_get().
>
> You should get one of "data", "fragment" and "metadata" for data
> blocks, fragment blocks and metadata respectively.
>
> This information will go a long way in showing where the problem lies.

Here is a patch to count and the result.

----------------------------------------------------------------------
frag(3, 100) x -no-fragments(with, without)

O: no-fragments x inner ext3

A: frag=3 x without -no-fragments
B: frag=3 x with -no-fragments

C: frag=100 x without -no-fragments
-: frag=100 x with -no-fragments

	cat10		cache_get		read		zlib
	(sec,cpu)	(meta,frag,data)	(meta,data)	(meta,data)
	----------------------------------------------------------------------
O	.06, 35%	92, -, 41		3, 44		2, 3557
A	.09, 113%	12359, 81, 22		4, 90		6, 6474
B	.07, 104%	12369, -, 109		3, 100		5, 3484
C	.06, 112%	12381, 80, 35		4, 53		6, 3650

- the case O is b.img in my first mail, and the case A is a.img.
- the "cat10" column is the result of time command as described in my
  first mail.
- all these numbers just show the trend and the small difference doesn't
  have much meaning.
- with -no-fragments option (case B),
  + the number of zlib call is reduced.
  + the CPU usage is not reduced much.
  + the number of cache_get for data increses.
  + the number of read for data may increse too.
- even with the compressed fragments, by increasing
  CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE it shows similar performance (case
  C),
  + the number of zlib call is reduced.
  + the CPU usage is not reduced much.
  + the number of cache_get for data may increse.
  + the number of read for data may decrese.

I am not sure the differece of cache_get/read for data between cases is
so meaningful.
But it surely shows high CPU usage in squashfs and I guess it is caused
by cache_get for metadata. The number of zlib compression may not be
related to this CPU usage much.


J. R. Okajima