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 -- 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
