linux-kernel - Re: [PATCH v10 0/6] mm / virtio: Provide support for unused page reporting

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]

Date:   Tue, 24 Sep 2019 17:32:26 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>,
        Alexander Duyck <alexander.duyck@...il.com>
Cc:     virtio-dev@...ts.oasis-open.org, kvm@...r.kernel.org,
        mst@...hat.com, dave.hansen@...el.com,
        linux-kernel@...r.kernel.org, willy@...radead.org,
        linux-mm@...ck.org, vbabka@...e.cz, akpm@...ux-foundation.org,
        mgorman@...hsingularity.net, linux-arm-kernel@...ts.infradead.org,
        osalvador@...e.de, yang.zhang.wz@...il.com, pagupta@...hat.com,
        konrad.wilk@...cle.com, nitesh@...hat.com, riel@...riel.com,
        lcapitulino@...hat.com, wei.w.wang@...el.com, aarcange@...hat.com,
        pbonzini@...hat.com, dan.j.williams@...el.com,
        alexander.h.duyck@...ux.intel.com
Subject: Re: [PATCH v10 0/6] mm / virtio: Provide support for unused page
 reporting

On 24.09.19 16:23, Michal Hocko wrote:
> On Wed 18-09-19 10:52:25, Alexander Duyck wrote:
> [...]
>> In order to try and keep the time needed to find a non-reported page to
>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
>> by the get_unreported_pages iterator to determine at what point it should
>> resume searching for non-reported pages. In order to guarantee pages do
>> not get past the scan I have modified add_to_free_list_tail so that it
>> will not insert pages behind the reported_boundary.
>>
>> If another process needs to perform a massive manipulation of the free
>> list, such as compaction, it can either reset a given individual boundary
>> which will push the boundary back to the list_head, or it can clear the
>> bit indicating the zone is actively processing which will result in the
>> reporting process resetting all of the boundaries for a given zone.
> 
> Is this any different from the previous version? The last review
> feedback (both from me and Mel) was that we are not happy to have an
> externally imposed constrains on how the page allocator is supposed to
> maintain its free lists.
> 
> If this is really the only way to go forward then I would like to hear
> very convincing arguments about other approaches not being feasible.

Adding to what Alexander said, I don't consider the other approaches
(especially the bitmap-based approach Nitesh is currently working on)
infeasible. There might be more rough edges (e.g., sparse zones) and
eventually sometimes a little more work to be done, but definitely
feasible. Incorporating stuff into the buddy might make some tasks
(e.g., identify free pages) more efficient.

I still somewhat like the idea of capturing hints of free pages (in
whatever data structure) and then going over the hints, seeing if the
pages are still free. Then only temporarily isolating the still-free
pages, reporting them, and un-isolating them after they were reported. I
like the idea that the pages are not fake-allocated but only temporarily
blocked. That works nicely e.g., with the movable zone (contain only
movable data).

But anyhow, after decades of people working on free page
hinting/reporting, I am happy with anything that gets accepted upstream :D

-- 

Thanks,

David / dhildenb