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 97404D0E6C1 for ; Mon, 21 Oct 2024 08:14:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1733A6B0096; Mon, 21 Oct 2024 04:14:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FCAE6B0098; Mon, 21 Oct 2024 04:14:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE0006B0099; Mon, 21 Oct 2024 04:14:49 -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 CE6286B0096 for ; Mon, 21 Oct 2024 04:14:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8E12781719 for ; Mon, 21 Oct 2024 08:14:36 +0000 (UTC) X-FDA: 82696897374.20.CD882E5 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf21.hostedemail.com (Postfix) with ESMTP id BA6A01C0004 for ; Mon, 21 Oct 2024 08:14:18 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.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=1729498339; 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=Tj3QG30adBWhDut9CaW8QYsJ8BaUGsCoGA63oChxmbs=; b=pXaXai9WPV7V3MNKLD+AmxObH9Qlq7ho5ayyqXwf8VmXKZokr2xKI7lJeGSTB0rGrVIRPr wq/Gpklb9cGmbQQJwibVNH4RDWzsGDuh48DjJXPrOuU9YnU+LknOXfm01FEX+KkOHdvqFq MTdYzzcHy97KzNX53w/VUfC/38SH+is= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729498339; a=rsa-sha256; cv=none; b=V/ZZHdRcKWvy64zHePYKr0qsAOPhy+iJHgHSkRJPS6Rx5/c7vw06JToDqtToFvHooy/qRR Aheur3BP+VlN77X2dyGSDCbmywR8dTp2uuwHDKUm/ygtm0iapdlMFAf2VU5Y7TY/2uLNJK INkYRnGiutNPPP5sR64pY0/jagb2aYc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4XX7MJ33JCzfdMY; Mon, 21 Oct 2024 16:12:12 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id C37E818005F; Mon, 21 Oct 2024 16:14:41 +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 16:14:41 +0800 Message-ID: Date: Mon, 21 Oct 2024 16:14:40 +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> <789aba5c-e2dd-4b4c-bfac-8d534c7a9211@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: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Queue-Id: BA6A01C0004 X-Stat-Signature: ss6t8dotz4qxkp5yphho1xmujjsd5bge X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729498458-32848 X-HE-Meta: U2FsdGVkX1/o1W++GgW6QJ7HMwYs53BZcwLJEkBe8pMG7E1qA4aPJgG2Ek6qUFGiT8xm2o5QdqIj5v1igvIzC/NeeQ3dxtFZG3ZuoqidHQKN3NbTuuzzltPWHfy47ydIjwCXIfqSNAuOfJYt/FYKZNZ9z4gJCaKK77dpuJ47X2AkyHJFrA2mtMGCM6I3M34y4jwdjJiW1vw2zwWc46PNUjMNEr7ckhz9Owf1G8EI7QoVJrrsNNmDR0d7h7MO5melAhMLWjYa44YlpNS2Z5asPy0hzN/pJWW7KglUGu+pHq7uobf8kgQlSSqX9nEn8cs1Vh0efB1Q4jtOM07prOjbSzqqvhgO4GPoCk0wN5DsX+6V+InToFaZtuNfIU5yD/t1MP9sZYKvUB3xoTo5c1VXm9+4R7oH+4YnAQUZx9HEM9FnH0yqbzqDlqhO2yVzHL6yI8ndHEfUwH3XcVCgLubTNzh70WEhp0/iSuTZbNmOkj0HINloi4Qd94hYUYcHl5glSx3bKph8U37vm4L/5V4S7VUx2YCj4IOIYtjIzpiVIYgLcdtjazFdt7152zfSTr6M4hb9CHcoacNzMTkBjbyRLw3GJl3/h7QifvCBXHxMNF4kGKJszFEK5mvMTGVLinoy0GStpN/kHSWDlTctQvGhXBJ7N55rKKTd5kQxGQahmqJPU0iNcmoZN14fSQcwl/DjsxvoIprx7XNaG4LJh7e1kY2Oq2Gw5xEEnXYMlj2IRk9602BRlANV5OhNfBu/B3R0T9wiNPENOQ5yJwgZrEwEShuEggamH0S028yUvXjsPlL3jvI9SDyNdb59hNpA+iRjUAoWB+ZA6Va7mPXbZwrWKrRv4zL1Csa2BxpH4NYXmAQS/6ArqGz3FseaEQ74duEWuQ27iToHV3sGiUqdYKuyag/X/CW/D5GNKIy8JSaU0Pwo40Cb3mV3ueumZZXcddc4vHuFiqIzQVIZokDGgGG Wa8x4W0i oGGrgXQFyawJiqixmb9kPXLdphaJM8itOqcZtXgxogrEvEtchlFviVnV5AZ+0HMSIcfBGv5a/+Cie5aSWUS226qLvuPnt+1n2iZFnGErQUR9eJPd585L0kf5YtQ8TZAW6eiH7KzB97PdIc7J8Ktwz0HKQUlRGTpS9SYR7uiICBZtuBtWC44rek20U/BbRqUEyGBBWcLMhDuLK91lGrErD6X5Myg96epkFG71YFHdE6f79T/zjPC1DB3hLNmABCVaOJ9D5kLtKD+TnTwVsv1md7SXndkDYiVptUPlr 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 15:55, Barry Song wrote: > On Mon, Oct 21, 2024 at 8:47 PM Barry Song <21cnbao@gmail.com> wrote: >> >> On Mon, Oct 21, 2024 at 7:09 PM Kefeng Wang wrote: >>> >>> >>> >>> On 2024/10/21 13:38, Barry Song wrote: >>>> On Mon, Oct 21, 2024 at 6:16 PM Kefeng Wang wrote: >>>>> >>>>> >>>>> >>>>> 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. >>>>>>>> >>> ... >>> >>>>>> 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. >>>> >>>> we already have a helper like folio_zero_user()? >>>> it is not good enough? >>> >>> Since it is with many cond_resched(), the performance is worst... >> >> Not exactly? It should have zero cost for a preemptible kernel. >> For a non-preemptible kernel, it helps avoid clearing the folio >> from occupying the CPU and starving other processes, right? > > --- a/mm/shmem.c > +++ b/mm/shmem.c > > @@ -2393,10 +2393,7 @@ static int shmem_get_folio_gfp(struct inode > *inode, pgoff_t index, > * it now, lest undo on failure cancel our earlier guarantee. > */ > > 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)); > + folio_zero_user(folio, vmf->address); > flush_dcache_folio(folio); > folio_mark_uptodate(folio); > } > > Do we perform better or worse with the following? Here is for SGP_FALLOC, vmf = NULL, we could use folio_zero_user(folio, 0), I think the performance is worse, will retest once I can access hardware.