linux-kernel - Re: [PATCH] kswapd: no need reclaim cma pages triggered by unmovable allocation

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: <YE+Gs13F8nV1Z1/d@dhcp22.suse.cz>
Date:   Mon, 15 Mar 2021 17:09:23 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     zhou <xianrong_zhou@....com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        mgorman@...e.de, willy@...ux.intel.com, rostedt@...dmis.org,
        mingo@...hat.com, vbabka@...e.cz, rientjes@...gle.com,
        pankaj.gupta.linux@...il.com, bhe@...hat.com, ying.huang@...el.com,
        iamjoonsoo.kim@....com, minchan@...nel.org,
        ruxian.feng@...nssion.com, kai.cheng@...nssion.com,
        zhao.xu@...nssion.com, zhouxianrong@....com,
        zhou xianrong <xianrong.zhou@...nssion.com>
Subject: Re: [PATCH] kswapd: no need reclaim cma pages triggered by unmovable
 allocation

On Mon 15-03-21 16:46:33, David Hildenbrand wrote:
> On 13.03.21 09:31, zhou wrote:
[...]
> > This optimization can avoid ~3% unnecessary isolations from cma
> > (cma isolated / total isolated) with configuration of total 100Mb
> > cma pages.
> 
> Can you say a few words about interaction with ZONE_MOVABLE, which behaves
> similar to CMA? I.e., does the same apply to ZONE_MOVABLE? Is it already
> handled?

No, the movable zone shouldn't be affected as the reclaim is zone aware.
The problem is that CMA doesn't belong to any particular zone. This is
something Joonsoo worked in the past and I believe following up on that
work has been recommended last time a similar/same approach like this
patch was proposed.
-- 
Michal Hocko
SUSE Labs