Re: [PATCH v4 0/5] batched remove rmap in try_to_unmap_one()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3/14/2023 5:48 PM, Matthew Wilcox wrote:
> On Tue, Mar 14, 2023 at 10:16:09AM +0100, David Hildenbrand wrote:
>> On 14.03.23 04:09, Yin Fengwei wrote:
>>>    For long term with wider adoption of large folio in kernel (like large
>>>    folio for anonymous page), MADV_PAGEOUT needs be updated to handle
>>>    large folio as whole to avoid splitting it always.
>>
>> Just curious what the last sentence implies. Large folios are supposed to be
>> a transparent optimization. So why should we pageout all surrounding
>> subpages simply because a single subpage was requested to be paged out? That
>> might harm performance of some workloads ... more than the actual split.
>>
>> So it's not immediately obvious to me why "avoid splitting" is the correct
>> answer to the problem at hand.
> 
> Even if your madvise() call says to pageout all pages covered by a
> folio, the current code will split it.  That's what needs to be fixed.
Yes. This is my understanding.

> 
> At least for anonymous pages, using large folios is an attempt to treat
> all pages in a particular range the same way.  If the user says to only
> page out some of them, that's a big clue that these pages are different
> from the other pages, and so we should split a folio where the madvise
> call does not cover every page in the folio.
Yes. This is my understanding also. :).

> 
> I'm less convinced that argument holds for page cache pages.
Can you explain more about this? My understanding is that if we need
to reclaim the large folio for page cache, it's better to reclaim the
whole folio.


Regards
Yin, Fengwei





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux