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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87CB2D3C93D for ; Mon, 21 Oct 2024 05:16:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F35D6B007B; Mon, 21 Oct 2024 01:16:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A3BE6B0082; Mon, 21 Oct 2024 01:16:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAD146B0089; Mon, 21 Oct 2024 01:16:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CEA626B007B for ; Mon, 21 Oct 2024 01:16:46 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B4D361A164B for ; Mon, 21 Oct 2024 05:16:19 +0000 (UTC) X-FDA: 82696449360.04.F03AE09 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf08.hostedemail.com (Postfix) with ESMTP id 62F4B16000C for ; Mon, 21 Oct 2024 05:16:33 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729487754; a=rsa-sha256; cv=none; b=uVdDjNUU9AzLYmCyIkuEwmXfvLEQvAeibEXWtzQjyZ9VlquxvTz3OzaZnogjCN+okI6WJl wIPNvrtbr8KrHHnMWyXnGw4ZH9syPSisBAN3UYHiY449AigLGXTxa4ZqPjhw+uednU0MKH DmvZLea+Vi6XJIs+TflywOlAl/42llw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729487754; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wFM8WXXaxV6X3VogdKqC9u4lKti1MjfCGgAgv4Rqp3I=; b=ed+SBaz7UMlRWWx0u/o5lz+msKz0mGvGM0R6Ut94hDoRfY7zzZPMoYYuA2Otz8x13u8Zx7 GDlKaQPof6jVVdkAytvQCaJJKo5S7vjVo1DkQveElKCsCyqVTvgbzmyMTlki6fITIG8aOY SYjoK8iVQwDtFTWeULfgNBrvEw32T2A= Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4XX3QP3GgZzpVKF; Mon, 21 Oct 2024 13:14:37 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id DE21D14010D; Mon, 21 Oct 2024 13:16:34 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 21 Oct 2024 13:16:34 +0800 Message-ID: Date: Mon, 21 Oct 2024 13:16:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: shmem: convert to use folio_zero_range() To: Barry Song <21cnbao@gmail.com> CC: Matthew Wilcox , Andrew Morton , Hugh Dickins , David Hildenbrand , Baolin Wang , References: <20241017142504.1170208-1-wangkefeng.wang@huawei.com> <20241017142504.1170208-2-wangkefeng.wang@huawei.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Rspamd-Queue-Id: 62F4B16000C X-Rspamd-Server: rspam01 X-Stat-Signature: ct5hzugq4qmywt3t3rehtft4zz7macg5 X-HE-Tag: 1729487793-304145 X-HE-Meta: U2FsdGVkX19YtBiXlQoKpxWEaZRw9sSrco+sdA2CnF51WSX9MFsSH2ixp3ihL4LKzVjSdLWab4xBYKovTtEO9fjG1g6vqm7eXIfHpih5cx8fuU1Zg8N98oCnc0d23Var7IdrRALJrUxWoqCfgfjGxaSmhqoK5samaakS9nrGbziNtyEPG/BQKodY5sUNosoXSvZZWve4W8z/P0JP6GhiPXmHqxSrosLg6mED56dgKQ4mPfg7hfT+rm7RQoHzBE+jQpnhR1Madzd1d5mlDZkdybqovwowCpBaf3Mxpp0eL231dt3dYeOkR3170WP4p/ySYWShaIqhhwclBWKcO48PihPrVnu/Q3y65F0tEOU9BPIEsAJl+lYHchPUTsMGKgKAgwKysEPFkqI69kwATwjP4o2YEGy5aU4OIfwXfG5hXM/4O5FR3vr4SIMZ91hQfxhGR0WQvugm6NxGjNg7REsFI7bXPwjBOGj7R/Dr+ECcpW+CTTQWjnPC6uMXyaLZ0t2OOBx1Ul0kThFeMLgDtAgN8ihdG2z8PIGGHoE6kiSMdF4vRKl5hDdqnA8UvL6clHaaDzZ6fi4Vz91IYQXc3SOT77IswSigMcG7PI8V9QwEF49bZpO7bd/Dv1Jak0wAm/1kktXl4wajgklBRm0LL83Ma+gfKlb2nSptHV0JaIzFS1PcOYbULAT9TtHqaJ5IGLGYtIZykVcVySGU99vFytTW8fLqwFacIAw8zxJ1RT9PHbouJoZyMqQ649jF07g4nVQKtKCl7gA1Ko3pz0KYa2HuTzFrwMSQW7Y1Ui8VqkBsBXijukhsJrCH3qmoG5r1LxVtQkD34FnFu48T9Hd6di75DZcOxzHfl8zG7vpj3F/iS18i89zd9ym9ilcxrMhKG/cldb/20J7WgA2wPlTog9BIHUoCUN6RVWKMvVy/p7xaBlKmXHGIxsFOIB+R+A3rMu0TxDvU1Z5ia1kvDM/znuO 0v76R2TT XtiIsSw0+Jwo/7+OfGgEAFgG5xGU6Q0oQeyiyy5Rkx2xh1JKOFpm5Ak0IXlYgwMP5sROlMVEKd3H0ReLNGka/IY/9e5R8I6SsmRfxTDPI40lf39J/F0zLI1tgrO0X9XHWV2cMikTvEzZKKXEwHKzaJmKHKaj7z2CAxIajD2CHFDvIM1qLOH4tM6UlJ3mFSrWw5sr67W1N3wzWu6ZqFFeBvDbVS5bOZPzAhWHJhizbIZoLvGxpyDjoMJu3kAgeSdiOHoxmTAizObAn4Fs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/10/21 12:15, Barry Song wrote: > On Fri, Oct 18, 2024 at 8:48 PM Kefeng Wang wrote: >> >> >> >> On 2024/10/18 15:32, Kefeng Wang wrote: >>> >>> >>> On 2024/10/18 13:23, Barry Song wrote: >>>> On Fri, Oct 18, 2024 at 6:20 PM Kefeng Wang >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 2024/10/17 23:09, Matthew Wilcox wrote: >>>>>> On Thu, Oct 17, 2024 at 10:25:04PM +0800, Kefeng Wang wrote: >>>>>>> Directly use folio_zero_range() to cleanup code. >>>>>> >>>>>> Are you sure there's no performance regression introduced by this? >>>>>> clear_highpage() is often optimised in ways that we can't optimise for >>>>>> a plain memset(). On the other hand, if the folio is large, maybe a >>>>>> modern CPU will be able to do better than clear-one-page-at-a-time. >>>>>> >>>>> >>>>> Right, I missing this, clear_page might be better than memset, I change >>>>> this one when look at the shmem_writepage(), which already convert to >>>>> use folio_zero_range() from clear_highpage(), also I grep >>>>> folio_zero_range(), there are some other to use folio_zero_range(). >>>>> >>>>> fs/bcachefs/fs-io-buffered.c: folio_zero_range(folio, 0, >>>>> folio_size(folio)); >>>>> fs/bcachefs/fs-io-buffered.c: folio_zero_range(f, >>>>> 0, folio_size(f)); >>>>> fs/bcachefs/fs-io-buffered.c: folio_zero_range(f, >>>>> 0, folio_size(f)); >>>>> fs/libfs.c: folio_zero_range(folio, 0, folio_size(folio)); >>>>> fs/ntfs3/frecord.c: folio_zero_range(folio, 0, >>>>> folio_size(folio)); >>>>> mm/page_io.c: folio_zero_range(folio, 0, folio_size(folio)); >>>>> mm/shmem.c: folio_zero_range(folio, 0, folio_size(folio)); >>>>> >>>>> >>>>>> IOW, what performance testing have you done with this patch? >>>>> >>>>> No performance test before, but I write a testcase, >>>>> >>>>> 1) allocate N large folios (folio_alloc(PMD_ORDER)) >>>>> 2) then calculate the diff(us) when clear all N folios >>>>> clear_highpage/folio_zero_range/folio_zero_user >>>>> 3) release N folios >>>>> >>>>> the result(run 5 times) shown below on my machine, >>>>> >>>>> N=1, >>>>> clear_highpage folio_zero_range folio_zero_user >>>>> 1 69 74 177 >>>>> 2 57 62 168 >>>>> 3 54 58 234 >>>>> 4 54 58 157 >>>>> 5 56 62 148 >>>>> avg 58 62.8 176.8 >>>>> >>>>> >>>>> N=100 >>>>> clear_highpage folio_zero_range folio_zero_user >>>>> 1 11015 11309 32833 >>>>> 2 10385 11110 49751 >>>>> 3 10369 11056 33095 >>>>> 4 10332 11017 33106 >>>>> 5 10483 11000 49032 >>>>> avg 10516.8 11098.4 39563.4 >>>>> >>>>> N=512 >>>>> clear_highpage folio_zero_range folio_zero_user >>>>> 1 55560 60055 156876 >>>>> 2 55485 60024 157132 >>>>> 3 55474 60129 156658 >>>>> 4 55555 59867 157259 >>>>> 5 55528 59932 157108 >>>>> avg 55520.4 60001.4 157006.6 >>>>> >>>>> >>>>> >>>>> folio_zero_user with many cond_resched(), so time fluctuates a lot, >>>>> clear_highpage is better folio_zero_range as you said. >>>>> >>>>> Maybe add a new helper to convert all folio_zero_range(folio, 0, >>>>> folio_size(folio)) >>>>> to use clear_highpage + flush_dcache_folio? >>>> >>>> If this also improves performance for other existing callers of >>>> folio_zero_range(), then that's a positive outcome. >>> >>> >>> rm -f /tmp/test && fallocate -l 20G /tmp/test && fallocate -d -l 20G / >>> tmp/test && time fallocate -l 20G /tmp/test >>> >>> 1）mount always(2M folio) >>> with patch without patch >>> real 0m1.214s 0m1.111s >>> user 0m0.000s 0m0.000s >>> sys 0m1.210s 0m1.109s >>> >>> With this patch, the performance does have regression, >>> folio_zero_range() is bad than clear_highpage + flush_dcache_folio >>> >>> with patch >> >> Oh, this should without patch since it uses clear_highpage, >> >>> >>> 99.95% 0.00% fallocate [kernel.vmlinux] [k] vfs_fallocate >>> vfs_fallocate >>> - shmem_fallocate >>> 98.54% __pi_clear_page >>> - 1.38% shmem_get_folio_gfp >>> filemap_get_entry >>> >> and this one is with patch >>> without patch >>> 99.89% 0.00% fallocate [kernel.vmlinux] [k] shmem_fallocate >>> shmem_fallocate >>> - shmem_get_folio_gfp >>> 90.12% __memset >>> - 9.42% zero_user_segments.constprop.0 >>> 8.16% flush_dcache_page >>> 1.03% flush_dcache_folio >>> >>> >>> >>> >>> 2）mount never (4K folio) >>> real 0m3.159s 0m3.176s >>> user 0m0.000s 0m0.000s >>> sys 0m3.150s 0m3.169s >>> >>> But with this patch, the performance is improved a little, >>> folio_zero_range() is better than clear_highpage + flush_dcache_folio >>> >> >> For 4K, the result is fluctuating, so maybe no different. > > hi Kefeng, > what's your point? providing a helper like clear_highfolio() or similar? Yes, from above test, using clear_highpage/flush_dcache_folio is better than using folio_zero_range() for folio zero(especially for large folio), so I'd like to add a new helper, maybe name it folio_zero() since it zero the whole folio. > >> >>> with patch >>> 97.77% 3.37% fallocate [kernel.vmlinux] [k] shmem_fallocate >>> - 94.40% shmem_fallocate >>> - 93.70% shmem_get_folio_gfp >>> 66.60% __memset >>> - 7.43% filemap_get_entry >>> 3.49% xas_load >>> 1.32% zero_user_segments.constprop.0 >>> >>> without patch >>> 97.82% 3.22% fallocate [kernel.vmlinux] [k] shmem_fallocate >>> - 94.61% shmem_fallocate >>> 68.18% __pi_clear_page >>> - 25.60% shmem_get_folio_gfp >>> - 7.64% filemap_get_entry >>> 3.51% xas_load >>>> >>>>> >>>>> >>>>>> >>>>>>> if (sgp != SGP_WRITE && !folio_test_uptodate(folio)) { >>>>>>> - long i, n = folio_nr_pages(folio); >>>>>>> - >>>>>>> - for (i = 0; i < n; i++) >>>>>>> - clear_highpage(folio_page(folio, i)); >>>>>>> - flush_dcache_folio(folio); >>>>>>> + folio_zero_range(folio, 0, folio_size(folio)); >>>>>>> folio_mark_uptodate(folio); >>>>>>> } >>>>>> >>>>> >>>>> >>>> >>>> Thanks >>>> Barry >>> >>> >>