From: Dave Hansen <dave.hansen@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Mel Gorman <mgorman@techsingularity.net>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>,
Dan Williams <dan.j.williams@intel.com>,
David Hildenbrand <david@redhat.com>,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [RFC PATCH 0/4] mm: Add PG_zero support
Date: Mon, 13 Apr 2020 09:43:41 -0700 [thread overview]
Message-ID: <25f0bab2-439e-9f78-8637-d4f7cac714cc@intel.com> (raw)
In-Reply-To: <20200413094714.432b5841@w520.home>
On 4/13/20 8:47 AM, Alex Williamson wrote:
>> You can delay pinning until the device is actually used. That should be
>> late enough for the host to figure out whether a paravirtualized IOMMU
>> is in place.
> So the guest enables the bus master bit in the command register and at
> that point we'd stall the VM for an indeterminate length of time while
> we potentially pin all memory, and hope that both the user and the host
> has the resources to account and allocate that memory, otherwise the
> VM suddenly crashes? All of this potentially taking place in the
> pre-boot environment to support option ROMs as well. A delay starting
> the VM seems a lot more predictable. Thanks,
BTW, there are a million ways to speed up VM startup without both
complicating the core VM *and* slowing down everybody that gets a
speedup from cache-hot pages coming out of the allocator.
Use ramfs or hugetlbfs files. Have a bunch of them sitting around,
preallocated (and zeroed) and dole them out as VMs start up.
Instead of complicating the core VM, do the pre-zeroing in hugetlbfs.
Zeroing at the time the pages get added to the pool wouldn't be the
worst thing and wouldn't touch the core VM.
next prev parent reply other threads:[~2020-04-13 16:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-12 9:07 [RFC PATCH 0/4] mm: Add PG_zero support liliangleo
2020-04-13 1:43 ` Dave Hansen
2020-04-13 14:49 ` Alex Williamson
2020-04-13 15:14 ` Dave Hansen
2020-04-13 15:25 ` Raj, Ashok
2020-04-13 15:47 ` Alex Williamson
2020-04-13 16:43 ` Dave Hansen [this message]
2020-04-14 12:01 ` David Hildenbrand
2020-04-14 15:07 ` Alexander Duyck
2020-04-14 15:40 ` Daniel Jordan
2020-04-14 15:44 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25f0bab2-439e-9f78-8637-d4f7cac714cc@intel.com \
--to=dave.hansen@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=alexander.h.duyck@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).