Re: Q. cache in squashfs?

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

Phillip Lougher:
> > The -no-fragments shows better performance, but it is very small.
> > It doesn't seem that the number of fragment blocks is large on my test
> > environment.
>
> That is *very* surprising.  How many fragments do you have?

Actually -no-fragments could reduce the number of zlib_inflate()
expectedly. But the performance didn't improve much, particulary CPU
usage.
So I removed -no-fragments option again. This is what I forgot to write
in my mail. I hope one your big mystery solved.

$ sq4.0.wcvs/squashfs/squashfs-tools/mksquashfs  /bin  /tmp/a.img -no-progress -noappend -keep-as-directory -comp gzip
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on /tmp/a.img, block size 131072.

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
	compressed data, compressed metadata, compressed fragments
	duplicates are removed
Filesystem size 2236.52 Kbytes (2.18 Mbytes)
	47.19% of uncompressed filesystem size (4739.02 Kbytes)
Inode table size 1210 bytes (1.18 Kbytes)
	36.87% of uncompressed inode table size (3282 bytes)
Directory table size 851 bytes (0.83 Kbytes)
	63.70% of uncompressed directory table size (1336 bytes)
Number of duplicate files found 1
Number of inodes 98
Number of files 84
Number of fragments 28
Number of symbolic links  12
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 2
Number of ids (unique uids + gids) 2
Number of uids 2
	root (0)
	jro (1000)
Number of gids 2
	root (0)
	jro (1000)


> It is fragments and metadata blocks which show the potential for
> repeated re-reading on random access patterns.

Ok, then I'd focus metadata.
Increasing SQUASHFS_CACHED_BLKS	to (8<<10) didn't help the performance
for my case.

Here is my thought.
squashfs_read_metadata() is called very many times, from (every?) lookup
or file read. In squashfs_cache_get(), the search loop runs every time
with a spinlock held. That is why I thought the search is the CPU eater.
"100" is not a problem.


J. R. Okajima