From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 948D3C47DD3 for ; Mon, 22 Jan 2024 04:41:31 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4TJHcB1cLtz3brc for ; Mon, 22 Jan 2024 15:41:30 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.alibaba.com (client-ip=115.124.30.111; helo=out30-111.freemail.mail.aliyun.com; envelope-from=hsiangkao@linux.alibaba.com; receiver=lists.ozlabs.org) Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4TJHc56K5Pz309c for ; Mon, 22 Jan 2024 15:41:24 +1100 (AEDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045176;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0W.0b9Nb_1705898477; Received: from 30.97.48.216(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0W.0b9Nb_1705898477) by smtp.aliyun-inc.com; Mon, 22 Jan 2024 12:41:18 +0800 Message-ID: Date: Mon, 22 Jan 2024 12:41:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] erofs: add a global page pool for lz4 decompression To: Chunhai Guo , "xiang@kernel.org" References: <20240109074143.4138783-1-guochunhai@vivo.com> <69711d55-f7a2-420b-9ba8-fa2921f66a4c@vivo.com> From: Gao Xiang In-Reply-To: <69711d55-f7a2-420b-9ba8-fa2921f66a4c@vivo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-erofs@lists.ozlabs.org" , "huyue2@coolpad.com" Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" Hi Chunhai, On 2024/1/12 09:58, Chunhai Guo wrote: > On 2024/1/10 14:45, Chunhai Guo wrote: >> On 2024/1/9 21:08, Gao Xiang wrote: >>> [你通常不会收到来自 hsiangkao@linux.alibaba.com 的电子邮件。请访问 >>> https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要] >>> >>> Hi Chunhai, >>> >>> On 2024/1/9 15:41, Chunhai Guo wrote: >>>> Using a global page pool for LZ4 decompression significantly reduces >>>> the >>>> time spent on page allocation in low memory scenarios. >>>> >>>> The table below shows the reduction in time spent on page allocation >>>> for >>>> LZ4 decompression when using a global page pool.  The results were >>>> obtained from multi-app launch benchmarks on ARM64 Android devices >>>> running the 5.15 kernel with an 8-core CPU and 8GB of memory. In the >>>> benchmark, we launched 16 frequently-used apps, and the camera app was >>>> the last one in each round. The data in the table is the average >>>> time of >>>> camera app for each round. >>>> After using the page pool, there was an average improvement of 150ms in >>>> the launch time of the camera app, which was obtained from systrace >>>> log. >>>> +--------------+---------------+--------------+---------+ >>>> |              | w/o page pool | w/ page pool |  diff   | >>>> +--------------+---------------+--------------+---------+ >>>> | Average (ms) |     3434      |      21      | -99.38% | >>>> +--------------+---------------+--------------+---------+ >>>> >>>> Based on the benchmark logs, 64 pages are sufficient for 95% of >>>> scenarios. This value can be adjusted from the module parameter. The >>>> default value is 0. >>>> >>>> This patch currently only supports the LZ4 decompressor, other >>>> decompressors will be supported in the next step. >>>> >>>> Signed-off-by: Chunhai Guo >>> >>> This patch looks good to me, yet we're in the merge window for v6.8. >>> I will address it after -rc1 is out since no stable tag these days. >>> >>> Also it would be better to add some results of changing max_distance >>> if you have more time to test. >> >> OK. I will reply to this email when the experiment is finished. > > Dear Xiang, > > The experiment is done and table below shows the results. We can find > that a 16k sliding window reduces 38.2% of time used in page allocation > for LZ4 decompression compared to a 64k sliding window. However, using a > global page pool is still far better than both of them. > > +--------------+---------------+--------------+---------+ > |              |   64k window  |  16k window  |  diff   | > +--------------+---------------+--------------+---------+ > | Average (ms) |     3364      |      2079    | -38.2%  | > +--------------+---------------+--------------+---------+ > > Thanks, Let's rebase this onto commit ("erofs: relaxed temporary buffers allocation on readahead") I will merge these after the rebase patch is received. Thanks, Gao Xiang