linux-kernel - [RFC 0/2] migrate: convert migrate_pages()/unmap_and

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-next>] [day] [month] [year] [list]

Date:   Tue,  1 Nov 2022 14:21:35 +0800
From:   Huang Ying <ying.huang@...el.com>
To:     linux-mm@...ck.org
Cc:     Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Huang Ying <ying.huang@...el.com>, Zi Yan <ziy@...dia.com>,
        Yang Shi <shy828301@...il.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Oscar Salvador <osalvador@...e.de>
Subject: [RFC 0/2] migrate: convert migrate_pages()/unmap_and_move() to use folios

The conversion is quite straightforward, just replace the page API to
the corresponding folio API.  migrate_pages() and unmap_and_move()
mostly work with folios (head pages) only.

One question is about THP.  Which is converted to large folio in the
patchset.  This is generally OK, because the code can work with
arbitrary order large folio at most times.  But some THP related
statistics (such as THP_MIGRATION_SUCCESS, etc.) are converted for
large folio with arbitrary order too.  Do we really care about the
order of large folio?  Do we need to be backward compatible strictly?

Best Regards,
Huang, Ying