linux-kernel - Re: [RFC PATCH 0/4] mm: Add PG

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: <f9a3be0b-fe8d-ca25-f0df-4b9fd1f0fed5@intel.com>
Date:   Sun, 12 Apr 2020 18:43:07 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Mel Gorman <mgorman@...hsingularity.net>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Dan Williams <dan.j.williams@...el.com>,
        David Hildenbrand <david@...hat.com>,
        Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [RFC PATCH 0/4] mm: Add PG_zero support

On 4/12/20 2:07 AM, liliangleo wrote:
> Zero out the page content usually happens when allocating pages,
> this is a time consuming operation, it makes pin and mlock
> operation very slowly, especially for a large batch of memory.
> 
> This patch introduce a new feature for zero out pages before page
> allocation, it can help to speed up page allocation.

I think the bar for getting something like this merged is going to be
pretty high.  We have a long history of zeroing close to page use for
cache warmth reasons.  Starting up big VMs which won't soon touch the
memory they are allocating is basically the most pathological case
against our approach since they don't *care* about cache warmth.

I'm also not sure it's something we _want_ to optimize for.

VFIO's unconditional page pinning is the real problem here IMNHO.  They
don't *really* need to pin the memory.  We just don't have good
paravirtualized IOMMU support or want to pay the runtime cost for
pin/unpin operations.  You *could* totally have speedy VM startup if
only the pages being accessed or having DMA performed to them were
allocated.  But, the hacks that are in place mean that everything must
be pinned.