在 2025/8/20 20:42, Matthew Wilcox 写道:
> On Wed, Aug 20, 2025 at 09:10:56AM +0800, Jinjiang Tu wrote:
>> 在 2025/8/19 23:52, Matthew Wilcox 写道:
>>> On Tue, Aug 19, 2025 at 10:06:53PM +0800, Jinjiang Tu wrote:
>>>> There are two meaningless folio refcount update for order0 folio in
>>>> filemap_map_pages(). First, filemap_map_order0_folio() adds folio refcount
>>>> after the folio is mapped to pte. And then, filemap_map_pages() drops a
>>>> refcount grabbed by next_uptodate_folio(). We could remain the refcount
>>>> unchanged in this case.
>>>>
>>>> With this patch, we can get 8% performance gain for lmbench testcase
>>>> 'lat_pagefault -P 1 file', the size of file is 512M.
>>> You don't explain why you move the folio_unlock() call
>> We should call folio_unlock() before folio_put(). In filemap_map_order0_folio(),
>> if we doesn't set folio into pte, we should unlock and put folio.
> I agree that folio_unlock() needs to be called before folio_put().
> What I don't understand is why we need to delay folio_unlock() until
> right before folio_put().  Can't we leave folio_unlock() where it
> currently is and only move the folio_put()?

In filemap_map_order0_folio(), assuming the page is hwpoisoned, we skip set_pte_range(),
the folio should be unlocked and put. If we only move folio_put() to filemap_map_order0_folio(),
the folio is unlocked when filemap_map_pages() doesn't hold any folio refcount.