Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space

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

 



On Tue, Nov 21, 2023 at 5:00 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
> > However, in swapcache_only mode, the scan count still increased when scan
> > non-swapcache pages because there are large number of non-swapcache pages
> > and rare swapcache pages in swapcache_only mode, and if the non-swapcache
> > is skipped and do not count, the scan of pages in isolate_lru_folios() can
> > eventually lead to hung task, just as Sachin reported [2].
>
> I find this paragraph really confusing! I guess what you meant to say is
> that a real swapcache_only is problematic because it can end up not
> making any progress, correct?
>
> AFAIU you have addressed that problem by making swapcache_only anon LRU
> specific, right? That would be certainly more robust as you can still
> reclaim from file LRUs. I cannot say I like that because swapcache_only
> is a bit confusing and I do not think we want to grow more special

That is my feeling as well. I don't like to have too many special
purposes modes either. It makes the whole process much harder to
reason. The comment seems to suggest it is not effective in some
situations. I am wondering if we can address that situation more
directly without the special mode. At the same time I am not very
familiar with the reclaim code path yet. I need to learn more about
this problem space to articulate my thoughts better . I can dig in
more, I might ask a lot of silly questions.

Chris

> purpose reclaim types. Would it be possible/reasonable to instead put
> swapcache pages on the file LRU instead?
> --
> Michal Hocko
> SUSE Labs
>





[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