[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZDTWoTTtS1JcuiI6@casper.infradead.org>
Date: Tue, 11 Apr 2023 04:40:17 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Vishal Moola <vishal.moola@...il.com>
Cc: Peng Zhang <zhangpeng362@...wei.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
mike.kravetz@...cle.com, sidhartha.kumar@...cle.com,
muchun.song@...ux.dev, wangkefeng.wang@...wei.com,
sunnanyong@...wei.com
Subject: Re: [PATCH v5 3/6] userfaultfd: convert copy_huge_page_from_user()
to copy_folio_from_user()
On Thu, Apr 06, 2023 at 07:28:44PM -0700, Vishal Moola wrote:
> > - flush_dcache_page(subpage);
> > -
> > cond_resched();
> > }
> > + flush_dcache_folio(dst_folio);
> > return ret_val;
> > }
>
> Moving the flush_dcache_page() outside the loop to be
> flush_dcache_folio() changes the behavior of the function.
>
> Initially, if it fails to copy the entire page, the function breaks out
> of the loop and returns the number of unwritten bytes without
> flushing the page from the cache. Now if it fails, it will still flush
> out the page it failed on, as well as any later pages it may not
> have gotten to yet.
I'm not sure this is worth worrying about. Failing to copy the entire
folio is unlikely, and if we do, flushing the entire folio instead of just
a few pages in it is harmless. Plus I have patches which significantly
optiise flush_dcache_folio() over flush_dcache_page() (for the majority
of architectures) and so I think this change is actually beneficial in
the long term.
Powered by blists - more mailing lists