From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: Re: Q. cache in squashfs? Date: Fri, 09 Jul 2010 21:24:50 +0900 Message-ID: <18172.1278678290@jrobl> References: <19486.1277347066@jrobl> <4C354CBE.70401@lougher.demon.co.uk> <6356.1278569327@jrobl> <15323.1278662033@jrobl> <4C36FAB1.6010506@lougher.demon.co.uk> Cc: linux-fsdevel@vger.kernel.org To: Phillip Lougher Return-path: Received: from mtoichi13.ns.itscom.net ([219.110.2.183]:57268 "EHLO mtoichi13.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754752Ab0GIMZP (ORCPT ); Fri, 9 Jul 2010 08:25:15 -0400 In-Reply-To: <4C36FAB1.6010506@lougher.demon.co.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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