All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chunhai Guo via Linux-erofs <linux-erofs@lists.ozlabs.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>,
	Chunhai Guo <guochunhai@vivo.com>,
	"xiang@kernel.org" <xiang@kernel.org>
Cc: "linux-erofs@lists.ozlabs.org" <linux-erofs@lists.ozlabs.org>,
	"huyue2@coolpad.com" <huyue2@coolpad.com>
Subject: Re: [PATCH v2] erofs: relaxed temporary buffers allocation on readahead
Date: Fri, 26 Jan 2024 03:42:48 +0000	[thread overview]
Message-ID: <369dbe84-ae27-40f0-8945-fd06b7b628a4@vivo.com> (raw)
In-Reply-To: <61c6c462-11cf-4e66-ab24-712e55f9cf19@linux.alibaba.com>

On 2024/1/26 10:47, Gao Xiang wrote:
> [你通常不会收到来自 hsiangkao@linux.alibaba.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification,以了解这一点为什么很重要]
>
> On 2024/1/26 10:41, Chunhai Guo wrote:
>> On 2024/1/22 15:42, Chunhai Guo wrote:
>>> On 2024/1/22 12:37, Gao Xiang wrote:
>>>> [你通常不会收到来自 hsiangkao@linux.alibaba.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification,以了解这一点为什么很重要]
>>>>
>>>> On 2024/1/22 11:49, Chunhai Guo wrote:
>>>>> On 2024/1/22 10:07, Gao Xiang wrote:
>>>>>> [你通常不会收到来自 hsiangkao@linux.alibaba.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification,以了解这一点为什么很重要]
>>>>>>
>>>>>> On 2024/1/20 22:55, Chunhai Guo wrote:
>>>>>>> Even with inplace decompression, sometimes extra temporary buffers are
>>>>>>> still needed for decompression.  In low-memory scenarios, it would be
>>>>>>> better to try to allocate with GFP_NOWAIT on readahead first. That can
>>>>>>> help reduce the time spent on page allocation under memory pressure.
>>>>>>>
>>>>>>> There is an average reduction of 21% in page allocation time under
>>>>>> It would be better to add a table to show the absolute numbers too
>>>>>> (like what you did in the global pool commit.)  If it's possible, there
>>>>>> is no need to send a update version for this, just reply the updated
>>>>>> commit message and I will update the commit manually.
>>>>> The table below shows detailed numbers. The reduction I mentioned before
>>>>> was not accurate enough. Please help correct the improvement from 21% to
>>>>> 20.21%.
>>>>>
>>>>>
>>>>> +--------------+----------------+---------------+---------+
>>>>> |              | w/o GFP_NOWAIT | w/ GFP_NOWAIT |  diff   |
>>>>> +--------------+----------------+---------------+---------+
>>>>> | Average (ms) |     3364       |      2684     | -20.21% |
>>>>> +--------------+----------------+---------------+---------+
>>>> Did it test without the 16k sliding window change?
>>>> https://lore.kernel.org/linux-erofs/69711d55-f7a2-420b-9ba8-fa2921f66a4c@vivo.com
>>> The result is tested with 64k sliding window change.
>>>
>>>> Could you benchmark these two optimizations together to
>>>> show the extreme optimized case without a global pool?
>>>> With a new table if possible? I will add this to
>>>> the commit message too.
>>> OK. I will reply to this email when the benchmark is finished.
>> The benchmark has been completed and the table below shows that there is
>> an average 52.14% reduction in page allocation time with these two
>> optimizations.
>>
>> +--------------+----------------+---------------+---------+ | | 64k
>> window | 16k window | | | | w/o GFP_NOWAIT | w/ GFP_NOWAIT | diff |
>> +--------------+----------------+---------------+---------+ | Average
>> (ms) | 3364 | 1610 | -52.14% |
>> +--------------+----------------+---------------+---------+
>>
>> Table below summarizes the results of these three benchmarks.
>>
>> +--------------+----------------+----------------+---------------+---------------+
>> |              |   64k window   |   16k window   |   64k window  | 16k
>> window  |
>> |              | w/o GFP_NOWAIT | w/o GFP_NOWAIT | w/ GFP_NOWAIT | w/
>> GFP_NOWAIT |
>> +--------------+----------------+----------------+---------------+---------------+
>> | Average (ms) |     3364       |      2079      |      2684 |
>> 1610     |
>> +--------------+----------------+----------------+---------------+---------------+
>> |     diff     |                |     -38.19%    |     -20.81% |
>> -52.14%   |
>> +--------------+----------------+----------------+---------------+---------------+
>
> The tables shows in a mess, could you just list the
> numbers so I could refine this?

Sorry that there might be some issues with my email client. Here are the
numerical results below.
     64k window w/o GFP_NOWAIT : 3364
     16k window w/o GFP_NOWAIT : 2079, diff: -38.19%
     64k window w/  GFP_NOWAIT : 2684, diff: -20.81%
     16k window w/  GFP_NOWAIT : 1610, diff: -52.14%

Images size comparision:
     64k: 9117044 KB
     16k: 9113096 KB

Thanks,

>
> Thanks,
> Gao Xiang



  reply	other threads:[~2024-01-26  3:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20 14:55 [PATCH v2] erofs: relaxed temporary buffers allocation on readahead Chunhai Guo via Linux-erofs
2024-01-22  2:07 ` Gao Xiang
2024-01-22  3:49   ` Chunhai Guo via Linux-erofs
2024-01-22  4:37     ` Gao Xiang
2024-01-22  7:42       ` Chunhai Guo via Linux-erofs
2024-01-26  2:41         ` Chunhai Guo via Linux-erofs
2024-01-26  2:47           ` Gao Xiang
2024-01-26  3:42             ` Chunhai Guo via Linux-erofs [this message]
2024-01-26  3:49               ` Gao Xiang
2024-01-26  3:56                 ` 答复: " Chunhai Guo via Linux-erofs
2024-01-26  5:36                   ` [PATCH v3] " Gao Xiang
2024-01-26  5:36                     ` Gao Xiang
2024-01-26 10:46                     ` Yue Hu
2024-01-26 10:46                       ` Yue Hu
2024-01-26 13:30                       ` Gao Xiang
2024-01-26 13:30                         ` Gao Xiang
2024-01-26 14:01                       ` [PATCH v4] " Gao Xiang
2024-01-26 14:01                         ` Gao Xiang
2024-01-27  1:49                         ` Yue Hu
2024-01-27  1:49                           ` Yue Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=369dbe84-ae27-40f0-8945-fd06b7b628a4@vivo.com \
    --to=linux-erofs@lists.ozlabs.org \
    --cc=guochunhai@vivo.com \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=huyue2@coolpad.com \
    --cc=xiang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.