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 8FF66D3C55A for ; Fri, 18 Oct 2024 07:32:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 222CD6B0083; Fri, 18 Oct 2024 03:32:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D3216B00A5; Fri, 18 Oct 2024 03:32:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09BB86B00A6; Fri, 18 Oct 2024 03:32:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E09C26B0083 for ; Fri, 18 Oct 2024 03:32:28 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DB5DCC175B for ; Fri, 18 Oct 2024 07:32:15 +0000 (UTC) X-FDA: 82685904882.22.E774E21 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf04.hostedemail.com (Postfix) with ESMTP id 4F69240004 for ; Fri, 18 Oct 2024 07:32:09 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729236698; 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=vZPJL/G9BxdCBA1Q0PWeNR7k8G032/CNeigSVtnwmKQ=; b=iOIR6Q1DRmSLyUmoaBtxmn148Soxd7biLMLNs3eRjb2hLAmlSU5Qya8CsT0AQFPKnm5nAv Mxhee3tzARu518P0PC+Nxapy7sgwE/eeTUVPVvkIk4Wy81OiR+NqmvDmZXYKxb6ML8HCKf Mg2w8+sAc6t4NzIoVUdD7MG2WHpsrLc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729236698; a=rsa-sha256; cv=none; b=2qYlkcbs6xf4G9lVqhQQqLnUwF067v8dE1jOI+IwaRvQuVAxGBMBaYs6c/jYIKHuOm1QA7 Ut4JmjEe0OjF7DkoTmuOoQHP7EjlSuz6tej8/miwDTHblsBG1Q+SfnD0SdMDkdbUhxIkk6 d7H0kZiCiptCyFHCO+8N7+R/oC/c4vw= Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4XVGWl2VhRz1HL4X; Fri, 18 Oct 2024 15:28:03 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id B3EB0180043; Fri, 18 Oct 2024 15:32:18 +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; Fri, 18 Oct 2024 15:32:18 +0800 Message-ID: Date: Fri, 18 Oct 2024 15:32:17 +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: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Stat-Signature: feg8ukh1k797rjp86xfq7h8m4q3mhrii X-Rspamd-Queue-Id: 4F69240004 X-Rspamd-Server: rspam11 X-HE-Tag: 1729236729-629804 X-HE-Meta: U2FsdGVkX19us1qRf1D8BnUFu9VF4WbKaXWbYSWPvw7H7xEJueQK0jO09mEJM+dioUeffcpNpVvpSjwjts4MJOnEPJS1gjh4eyv7Rq959WXlh1Zk2fNIYF3vwn/ktCgLDSmSRSo42Yk4WsmIbhNOYwSbzyzg+ZDD8cwDGADTZqM3Q8xI0XLn+uTHnbyy0Xa8U9i42gFB+nIEcriGXCTJ5YKVvs+YF+djFqcrABXH2sRo1IhVdxTXPNx9ebDXJ1I1llcwPoIxCtsfBRjZpf268GgjunpIe/eyVaacSXBz2bdyxldB/rfDEPjEwzoObaVy1y38xJbuTqTxW/TfJIM+36Ef/JIB5V96LRd1VNHUwsGy3/WuIZyfVMdnmS1NfqagmOKM42VTlCA9qCSWVaohRBpJNDD0BQfU1ktWQFI4CwkGqFsQuVc+orGTsLqnwjo8KkORLHVy9Pd/M0NFpmiH6yqxymIpT4ySwEh2RA1GVDnxVMZVCW40X6KUTnXmFqqa3flT9DbdNaaRQUo6e9+/jYxSeaWGvhFuamOGdo4p2mzK8oSjg18bca5HlTBnCHgW33iBhro5XQBdmVQRLmRDserLeyCUB91kr6UtkHSqebWGvqhrtI28zH+OAy0a5mijZs4Ms3PlQZiafLLCfZ5j01wE5LCJIZdFnCLknm/Ccj/7lS6aD8Lvsg2BAcc4IkprFz3aSrBYF/8/UJ29c003197loHQvMZ0AtwZaTrwj5Yp4QnRL8Vob9ZYHzrJq5Bw1MbqnySfU/V5PGgj8pQYH6b+WQxV6T0egUx3+f5tWBotpB6Yr2idXwu8ihifv3Pw+G32HR/KCBRuM8p30SlAqMuTRnt9fM+heGjwaGvmgQpcacYsa4EQQTixAjSs+Bdf66oQuvNQh41Ynuk9S+Z00R7iC4NBocAU3NDfxX65jlvpQwYrH7vATTzsJyB1jv8My6h83ZKBlpeLtKOsgxR1 2qlLH4uQ XfIY5VS3cZCgLliBTbuXlc5PlWnXrcdZ+cDqlriZy21Ck1Cywe+/F1MeGSYRPVBVz4Cv0UDoChuqZcRBceX5nZpiKt6FAzyGQo8NeTAdf+5PDuzWGTxG79YMy4bnsPiWbWdgbp5OOCbYk6pMKHEEgCk8m7C6c0MvIJpUTbaYDUI0m9rc6zAz7a42OorxJkMvi+xrH+w1vjlTxUS0Z+g7421VKV63Vkn7wvMLiAygfsogk8xETU3jIRQjTNfAXcRzdlVOLxjEfoX7STBI= 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/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 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 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 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