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 7A173C433EF for ; Wed, 2 Feb 2022 13:33:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 002A48D00FB; Wed, 2 Feb 2022 08:33:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF46C8D00FA; Wed, 2 Feb 2022 08:33:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBBFC8D00FB; Wed, 2 Feb 2022 08:33:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id CCFD78D00FA for ; Wed, 2 Feb 2022 08:33:00 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7ACE1181DF774 for ; Wed, 2 Feb 2022 13:33:00 +0000 (UTC) X-FDA: 79097930520.30.C9CC0DE Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf22.hostedemail.com (Postfix) with ESMTP id A7874C0006 for ; Wed, 2 Feb 2022 13:32:59 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id k17so61027546ybk.6 for ; Wed, 02 Feb 2022 05:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=49C1ROc5LMrtI2IRPZaBsdDysSCIk+RUi4xq89kMC0Q=; b=ZUn4b/U/47chAtjr/MNZgInDUsb0hDXxHL7scO2+BXDqZ/qh4kyY8LfduGP0y8qrUM B+crmPB+2dqAT7UNK+hLLr52fLpJqU7vDGbUhpEe9iQUzEhcKq3ZbJMUc58jWxkBqarE 1Dr2MaC+DBWZj3cdUGlD4Z7UWv+bTW1WPHvH+aMPgF03x3ernz3nxhCxcyBEhTSUyyYA D5GL0fBA7KU3yB372PGQN3Tz0FXOP0aAK8wDmoAB3XK5d3v+AJgf/moxXK3ednbT+CzQ lCVzgt7v5Yjr4Iqjuhw16UIE7IBG/1fxDUP/wY7sf9I7N8f3TDg2NSmWNRX1SU0x/tH2 h+pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49C1ROc5LMrtI2IRPZaBsdDysSCIk+RUi4xq89kMC0Q=; b=O83PfI5EVCLSpeEKTAwPvbMT7oL4h5enJBkqZbdRGXmMYANQekk03ir/l3GB6BQScp wv7cn/Mu0byv9ePschcrgecptU6h1gCFuW2ANjkDLgckiVfbfFivXLFNCv44pewWQc0D jBB8lCQAUOM9rCpxY2tgXk07i9LWxmxSX5PZ1S1H7+skaYigMLxGREsp+kvqBet1ODc3 ofLrTQ2ythrMyTmW4WsD+Hqj9XLI7NY/olKhmgIIHiNv150gYC6k6qLqEyKY3ybfyTzG rMdLfOupYFrdK1korll1wdTl2zOs9Ya+4JRgOC5LNE3h5WOAsph+Yv9HgxmVHN6+L2t0 Y5Jg== X-Gm-Message-State: AOAM530RqlIZ0rRK8t3NRpH5KjEBa5J9QuWZujle4lXl0WPEh5YMGQgT sBXA1sInWMXJlj8MW9JSl06EwJUN9me2oZWmsXGm9Q== X-Google-Smtp-Source: ABdhPJzJyAQCcoB843YoDkZz7uho1finq6gZDC6Xle9/4bH7LFjvRLQxaJM13r6PFlV2ohOkBWRZcH+x7+2cHuVtJlc= X-Received: by 2002:a25:8f8e:: with SMTP id u14mr30612352ybl.495.1643808778816; Wed, 02 Feb 2022 05:32:58 -0800 (PST) MIME-Version: 1.0 References: <20220131160254.43211-1-songmuchun@bytedance.com> <20220131160254.43211-3-songmuchun@bytedance.com> <9fa0211a-aee2-22fb-d076-0464a4d8524c@oracle.com> In-Reply-To: <9fa0211a-aee2-22fb-d076-0464a4d8524c@oracle.com> From: Muchun Song Date: Wed, 2 Feb 2022 21:32:20 +0800 Message-ID: Subject: Re: [PATCH v3 2/5] mm: fix missing cache flush for all tail pages of compound page To: Mike Kravetz Cc: Andrew Morton , zi.yan@cs.rutgers.edu, "Kirill A. Shutemov" , David Rientjes , Lars Persson , Linux Memory Management List , LKML , Xiongchun duan , Zi Yan Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A7874C0006 X-Stat-Signature: pyfrfmrjcg7x6mhdn1ty6fkwwsizgeo1 X-Rspam-User: nil Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="ZUn4b/U/"; spf=pass (imf22.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-HE-Tag: 1643808779-585965 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: On Wed, Feb 2, 2022 at 7:33 AM Mike Kravetz wrote: > > On 1/31/22 08:02, Muchun Song wrote: > > The D-cache maintenance inside move_to_new_page() only consider one page, > > there is still D-cache maintenance issue for tail pages of compound page > > (e.g. THP or HugeTLB). THP migration is only enabled on x86_64, ARM64 > > and powerpc, while powerpc and arm64 need to maintain the consistency > > between I-Cache and D-Cache, which depends on flush_dcache_page() to > > maintain the consistency between I-Cache and D-Cache. In theory, the > > issue can be found on arm64 and powerpc. HugeTLB migration is enabled > > on arm, arm64, mips, parisc, powerpc, riscv, s390 and sh, while arm > > has handled the compound page cache flush in flush_dcache_page(), but > > most others do not. In theory, the issue exists on many architectures. > > Fix this by not using flush_dcache_folio() since it is not backportable. > > > > Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path") > > Fixes: 290408d4a250 ("hugetlb: hugepage migration core") > > Signed-off-by: Muchun Song > > Reviewed-by: Zi Yan > > --- > > mm/migrate.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/mm/migrate.c b/mm/migrate.c > > index c9296d63878d..c418e8d92b9c 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c > > @@ -933,9 +933,12 @@ static int move_to_new_page(struct page *newpage, struct page *page, > > if (!PageMappingFlags(page)) > > page->mapping = NULL; > > > > - if (likely(!is_zone_device_page(newpage))) > > - flush_dcache_page(newpage); > > + if (likely(!is_zone_device_page(newpage))) { > > + int i, nr = compound_nr(newpage); > > > > + for (i = 0; i < nr; i++) > > + flush_dcache_page(newpage + i); > > + } > > As you have already noted elsewhere, the arm64 version of flush_dcache_page > seems to handle this and flush the entire compound_page. Is this going to > flush the entire compound page compound_nr times? > Not flush cache compound_nr times but set PG_dcache_clean on page->flags compound_nr times. The definition of flush_dcache_page() on arm64 is as follows. void flush_dcache_page(struct page *page) { if (test_bit(PG_dcache_clean, &page->flags)) clear_bit(PG_dcache_clean, &page->flags); } So I have a plan to improve this, e.g. implement flush_dcache_folio() on arm64 and replace those multiple dcache flush with flush_dcache_folio(). void flush_dcache_folio(struct folio *folio) { if (test_bit(PG_dcache_clean, &folio->flags)) clear_bit(PG_dcache_clean, &folio->flags); } Thanks.