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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
