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 99847D0E6D6 for ; Mon, 21 Oct 2024 09:18:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 294976B0089; Mon, 21 Oct 2024 05:18:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21CCF6B008A; Mon, 21 Oct 2024 05:18:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 098366B008C; Mon, 21 Oct 2024 05:18:04 -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 DC70C6B0089 for ; Mon, 21 Oct 2024 05:18:03 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6BED0C17DA for ; Mon, 21 Oct 2024 09:17:47 +0000 (UTC) X-FDA: 82697057058.27.94500D1 Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf09.hostedemail.com (Postfix) with ESMTP id 6DA3A140006 for ; Mon, 21 Oct 2024 09:17:51 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EXzcQOeV; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729502131; 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:dkim-signature; bh=KdcaX6wPYAt1f77o9/UW4px+VDEulx7YJbdVBfo/qzY=; b=DckzmOusLh6ywnlnaC4lvhH3gT06Xts9I6rx6PoOsWvN+1tpYcuH3dL+VD9UEMYviCWHBw sii2nNFKcLBazxtgZGFtWngWnSGFdDqB2EdjJ1l3WVyuYpUC+N13UtnLRyImykvR1+EV3S EM6chfoZxjk1RYw8M1NAY9db/nq0UCI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729502131; a=rsa-sha256; cv=none; b=vwWvhwLVLIJBcuFolVsncgm2MH++cxBjrIWjVAds0s6KvDfP28ZUIlO1n1i4w7Js53u/cz 9PSGsCY0/hzYSNo8+vxFajxCPh5K9/IlM5H/rQJanqMr4M+Lkin/O06KUfjKJsbAPGl6fT DSc168MwKntyD9TMbEhtfXWmCmUeXR0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EXzcQOeV; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-84fb1225a89so1140462241.2 for ; Mon, 21 Oct 2024 02:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729502281; x=1730107081; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KdcaX6wPYAt1f77o9/UW4px+VDEulx7YJbdVBfo/qzY=; b=EXzcQOeV1bAakA/8lAd9wN3SIEviIXgU4UMgWni+mtXSrjtvZd4hT+Zi8BnsOXEQov mriubq0ddT36Iyg7xGnjTw4zvoXEGbWFc4fgFGFeJjm2Y+jkiAEyPtBONWqAO9Lmqkv0 8pPBPGKjWgmfwfUcOUQ1S2Te6DS9HP+T7A3bhITpykaJ/I+X8i+Q9HFKmO6lKeEwtLi5 Z4qjIQYwCO2bu+bxeRwAdPcqYsCqiXxaRopLx3BzmQHkEapC0vR3DfBPB7wwPhy1bChV T9gocrzJGvKqQ/wseqc43yTBmbUISXHBoz+yWtzltT+Mjx2LHtGOBIzZQsdhfNzUNgnP Ap4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729502281; x=1730107081; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KdcaX6wPYAt1f77o9/UW4px+VDEulx7YJbdVBfo/qzY=; b=u0czU6Uj32Oi3/cM8v/GAdg4g5NlGq/a8oQMfjnpUr82FB9LJT3/NKUa2Ze3mCqcf/ aKaAWYfL5zbGb9FkoeYniF7vICg5mtPVqzqr2Dm8mkqGDeUWqgTrHzm4P3DrSbZe0+sv Q09YNcjhFrwkNKNXTT59/1T99va9V80subkvQ25UpAys2rndLPCjc/K0wzsEITrEPHH/ sLKYyQgY4H5m/+TEhMxGU2zq1s5sPXCuJqh9UjPvr6RDI4tJsWijBghVNQDkb7fJBG82 J3Q9iBy+URSwF+omCmXLKKtbqNYaJZtcwxTl8WfCmIvywy9Vn5QF0iDMgT+ZMdzY23zA zvxg== X-Forwarded-Encrypted: i=1; AJvYcCWaU1u+G7dNM7MWlsvvEHdKdq+72/w027VVDywoccWl4X2mrxH7tXIXAb8Bc5qBMA1zPWRgzsgfEQ==@kvack.org X-Gm-Message-State: AOJu0Yx3cQxnNiu/J9KyxCF/3oHwNmDM/moYKydZfvEbgZqRSaeQqLIf fn2OCpxMvT2SqkBEtGJYan/UVznjTfBP6bXlzJY+kG1MZg23Y5teIMrLyT/eczSr4cpyWh3cD+y zC8EvI1LHZEQfGuaYr8/HO83Do+w= X-Google-Smtp-Source: AGHT+IFrFmvk84v9Qvhnob8io9rXQ7M8abfU64Ud/qGUGUIOCbkZSIN5IeVsMdXS3gam0rHzu4KfZFfmxDYeiSz98Bc= X-Received: by 2002:a05:6102:3a0d:b0:4a4:950a:cb1f with SMTP id ada2fe7eead31-4a5d6bb2175mr8750325137.22.1729502280713; Mon, 21 Oct 2024 02:18:00 -0700 (PDT) MIME-Version: 1.0 References: <20241017142504.1170208-1-wangkefeng.wang@huawei.com> <20241017142504.1170208-2-wangkefeng.wang@huawei.com> <789aba5c-e2dd-4b4c-bfac-8d534c7a9211@huawei.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 21 Oct 2024 22:17:49 +1300 Message-ID: Subject: Re: [PATCH] mm: shmem: convert to use folio_zero_range() To: Kefeng Wang Cc: Matthew Wilcox , Andrew Morton , Hugh Dickins , David Hildenbrand , Baolin Wang , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: hrj6r7uo959foabjdyn4thqy85xyfr7a X-Rspamd-Queue-Id: 6DA3A140006 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1729502271-174497 X-HE-Meta: U2FsdGVkX1/sTqd23c11bZFiuYbi+zNM3ybZa6Nvd/16D1DYXnkphx2fz/yTZM/ET9MPF99R1VUTUSG6CwLKVq4VxxqJ34Q/3UbqgZ0+aodjMsMMUtsUDLb8ElgAMmprItOuJcw0bk0Orn8mTbxthBXIH/+QV8GxmQLKM+Ztl5nxiwptcghHc8QHTK3iRVrSAI+qGQjgD9uhmYLjPo1fQXnHKl3OOq3tBEk0QZbldDtzibx/AJzdB7elaR/Q1mJGeF+ghOBy3FwJmICnc1iXrQyBgFS2GfCoxPuftEPgD0aEtNpetxWH82l/j1hdVLs8sWZafaA7YwUUk9ZcvCBeBd077LmajjlLOYTyUelEen28HdiBaVSfb9UmxQfPzKStHucUmyYxoD6kvZViZMtH18q5u+Alt1hEUmJVX2OzciLxdoMs5z9MxksoBEiccNASAwarmErfipkHY1ZzHrVNA41yW2nHe/yXxYhD09jRPdboYZ2OwD3xrat9sHMAhwVFnObOJIz3ySWyMS5By2AoeVQwWsHBcsciuHGLX31wO8W2TrBRKm0nvPwtsGY+7JC1alKI4aIWnXxw0/b8X0MCqlEb1+Wgh5afA/igemisi2y+dh+RDeBLHYSQYswCmVT9OFpBRxA37I67V/La6CVknakbaq8fIVBdHdJXqG6oIJ22TppENmW1gnHdiS4AOyDRUSG84ZmwoiBfjseYzKvNW7VdA2U5mxDHwm440hOwCbUQFxz/8b4cK0gx8J6BEQnSFKkx5TJn9FbvwP4ZgeHsMCGfWxN3+T/bqqnoP5SoBPhkZSATo3i7k0WWmJUCkhyleLaaHcvRwASaTAUSF8ZqnwekA1MMYwotQJ54VyGpCcrEAbaKy3jfBzzwwvz5jywZUJzsMn3DjYwTjDgWb/E624taeUOHyEtc6juY5e032DT4THcJfMsqZgZ8UbSE2i3OYImxn/utfpHFhOt0qa3 K+wcIR8A J+6Ju8f94ojt+xW2ZzRB24gzm0HgzpfL7bie+9Jg4kCLKFcgOXqACjhz0i8E9JBrZwXBhXcLtCpXUP43qVjY/2u9ZQgnsYKCltZJ9Wj0idqvuxUa/ZLtbh85MMLmXXCoj8GVInrvq0jWZNKyE4rivZcg7rbZSH4l6KE2F1ZooztpzKdX1GFirh/NJXV3MSHvMxbKAMRwKDSY9tXdnW5Pw/O7vS0NOIl9kJmEI8GkXvHlhLWPIZP+9y8odIC0yHDovCavrmDcYYnYgeHzCWG0Y3bYCwkjteNqX3TI5lb/6ht7oaIMhK0E921baCmy3UUwmdFejLSUhoFF2cdCVFlBCrwdJ2QSGG24iQPXGy6ybib2Px78/i+Rt+EGhWtlsK4i4sql+zgDdvgM97FWoEMPuMR9cec0phyJfPYUm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, 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 Mon, Oct 21, 2024 at 9:14=E2=80=AFPM Kefeng Wang wrote: > > > > On 2024/10/21 15:55, Barry Song wrote: > > On Mon, Oct 21, 2024 at 8:47=E2=80=AFPM Barry Song <21cnbao@gmail.com> = wrote: > >> > >> On Mon, Oct 21, 2024 at 7:09=E2=80=AFPM Kefeng Wang wrote: > >>> > >>> > >>> > >>> On 2024/10/21 13:38, Barry Song wrote: > >>>> On Mon, Oct 21, 2024 at 6:16=E2=80=AFPM Kefeng Wang wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 2024/10/21 12:15, Barry Song wrote: > >>>>>> On Fri, Oct 18, 2024 at 8:48=E2=80=AFPM 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=E2=80=AFPM 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 opt= imise 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 con= vert to > >>>>>>>>>> use folio_zero_range() from clear_highpage(), also I grep > >>>>>>>>>> folio_zero_range(), there are some other to use folio_zero_ran= ge(). > >>>>>>>>>> > >>>>>>>>>> fs/bcachefs/fs-io-buffered.c: folio_zero_range(folio= , 0, > >>>>>>>>>> folio_size(folio)); > >>>>>>>>>> fs/bcachefs/fs-io-buffered.c: folio_zero_ran= ge(f, > >>>>>>>>>> 0, folio_size(f)); > >>>>>>>>>> fs/bcachefs/fs-io-buffered.c: folio_zero_ran= ge(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=3D1, > >>>>>>>>>> clear_highpage folio_zero_range folio_zero_use= r > >>>>>>>>>> 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=3D100 > >>>>>>>>>> clear_highpage folio_zero_range folio_zero_use= r > >>>>>>>>>> 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=3D512 > >>>>>>>>>> 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 si= milar? > >>>>> > >>>>> Yes, from above test, using clear_highpage/flush_dcache_folio is be= tter > >>>>> 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 !=3D SGP_WRITE && !folio_test_uptodate(folio)) { > > - long i, n =3D folio_nr_pages(folio); > > - > > - for (i =3D 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 =3D NULL, we could use folio_zero_user(folio, > 0), I think the performance is worse, will retest once I can access > hardware. Perhaps, since the current code uses clear_hugepage(). Does using index << PAGE_SHIFT as the addr_hint offer any benefit? > >