From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: Re: Q. cache in squashfs? Date: Sat, 10 Jul 2010 14:07:54 +0900 Message-ID: <7545.1278738474@jrobl> References: <19486.1277347066@jrobl> <4C354CBE.70401@lougher.demon.co.uk> <6356.1278569327@jrobl> <15323.1278662033@jrobl> <4C36FAB1.6010506@lougher.demon.co.uk> <4C370017.4070604@lougher.demon.co.uk> Cc: linux-fsdevel@vger.kernel.org To: Phillip Lougher Return-path: Received: from mtoichi12.ns.itscom.net ([219.110.2.182]:63344 "EHLO mtoichi12.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849Ab0GJFIS (ORCPT ); Sat, 10 Jul 2010 01:08:18 -0400 In-Reply-To: <4C370017.4070604@lougher.demon.co.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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