linux-kernel - Re: [PATCH v6 2/2] mm: support large folios swap-in for zRAM-like devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4xS7S4+8ajHCWhEPcaL9ZEPaWL-=E7vuzBQAPhCV1L0og@mail.gmail.com>
Date: Sat, 17 Aug 2024 09:39:37 +1200
From: Barry Song <21cnbao@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: wangkefeng.wang@...wei.com, akpm@...ux-foundation.org, 
	baolin.wang@...ux.alibaba.com, chrisl@...nel.org, david@...hat.com, 
	hanchuanhua@...o.com, hannes@...xchg.org, hch@...radead.org, hughd@...gle.com, 
	kaleshsingh@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	mhocko@...e.com, minchan@...nel.org, nphamcs@...il.com, ryan.roberts@....com, 
	ryncsn@...il.com, senozhatsky@...omium.org, shakeel.butt@...ux.dev, 
	shy828301@...il.com, surenb@...gle.com, v-songbaohua@...o.com, 
	xiang@...nel.org, ying.huang@...el.com, yosryahmed@...gle.com
Subject: Re: [PATCH v6 2/2] mm: support large folios swap-in for zRAM-like devices

On Sat, Aug 17, 2024 at 9:17 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Fri, Aug 16, 2024 at 11:06:12AM +1200, Barry Song wrote:
> > When memcg approaches its limit, charging mTHP becomes difficult.
> > At this point, when the charge fails, we fallback to the next order
> > to avoid repeatedly retrying larger orders.
>
> Why do you always find the ugliest possible solution to a problem?
>

had definitely thought about charging order-0 as well in
alloc_swap_folio() when sending this
quick fix mainly for quick verification it can fix the problem. v7
will definitely charge order-0
in alloc_swap_folio().

> > @@ -4244,7 +4248,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >                               }
> >                               need_clear_cache = true;
> >
> > -                             if (mem_cgroup_swapin_charge_folio(folio,
> > +                             if (nr_pages == 1 && mem_cgroup_swapin_charge_folio(folio,
> >                                                       vma->vm_mm, GFP_KERNEL,
> >                                                       entry)) {
> >                                       ret = VM_FAULT_OOM;
>
> Just make alloc_swap_folio() always charge the folio, even for order-0.
>
> And you'll have to uncharge it in the swapcache_prepare() failure case.

I suppose this is done by folio_put() automatically.

Thanks
Barry