From: David Hildenbrand <david@redhat.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: linux-mm@kvack.org, mhocko@suse.com, dan.j.williams@intel.com,
Pavel.Tatashin@microsoft.com, linux-kernel@vger.kernel.org,
dave.hansen@intel.com, Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [RFC PATCH v2 0/4] mm, memory_hotplug: allocate memmap from hotadded memory
Date: Tue, 29 Jan 2019 11:08:32 +0100 [thread overview]
Message-ID: <23d64fa1-386d-bdbf-1546-77eb56fcebc6@redhat.com> (raw)
In-Reply-To: <20190129084359.65fzc4hqan265gii@d104.suse.de>
On 29.01.19 09:43, Oscar Salvador wrote:
> On Fri, Jan 25, 2019 at 09:53:35AM +0100, David Hildenbrand wrote:
> Hi David,
>
>> I only had a quick glimpse. I would prefer if the caller of add_memory()
>> can specify whether it would be ok to allocate vmmap from the range.
>> This e.g. allows ACPI dimm code to allocate from the range, however
>> other machanisms (XEN, hyper-v, virtio-mem) can allow it once they
>> actually support it.
>
> Well, I think this can be done, and it might make more sense, as we
> would get rid of some other flags to prevent allocating vmemmap
> besides mhp_restrictions.
Maybe we can also start passing a struct to add_memory() to describe
such properties. This would avoid having to change all the layers over
and over again. We would just have to establish some rules to avoid
breaking stuff. E.g. the struct always has to be initialized to 0 so new
features won't break any caller not wanting to make use of that.
E.g. memory block types (or if we come up with something better) would
also have to add new parameters to add_memory() and friends.
>
>>
>> Also, while s390x standby memory cannot support allocating from the
>> range, virtio-mem could easily support it on s390x.
>>
>> Not sure how such an interface could look like, but I would really like
>> to have control over that on the add_memory() interface, not per arch.
>
> Let me try it out and will report back.
>
> Btw, since you are a virt-guy, would it be do feasible for you to test the patchset
> on hyper-v, xen or your virtio-mem driver?
I don't have a XEN or Hyper-V installation myself. cc-ing Vitaly, maybe
he has time end resources to test on Hyper-V.
I'll be reworking my virtio-mem prototype soon and try with this
patchset than! But this could take a little bit longer as I have tons of
other stuff on my plate :) So don't worry about virtio-mem too much for now.
>
> Thanks David!
>
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-01-29 10:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 10:37 Oscar Salvador
2019-01-22 10:37 ` [RFC PATCH v2 1/4] mm, memory_hotplug: cleanup memory offline path Oscar Salvador
2019-01-22 10:37 ` [RFC PATCH v2 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug Oscar Salvador
2019-01-22 10:37 ` [RFC PATCH v2 3/4] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Oscar Salvador
2019-01-22 10:37 ` [RFC PATCH v2 4/4] mm, sparse: rename kmalloc_section_memmap, __kfree_section_memmap Oscar Salvador
2019-01-25 8:53 ` [RFC PATCH v2 0/4] mm, memory_hotplug: allocate memmap from hotadded memory David Hildenbrand
2019-01-29 8:43 ` Oscar Salvador
2019-01-29 10:08 ` David Hildenbrand [this message]
2019-01-30 21:52 ` Oscar Salvador
2019-01-31 7:23 ` Michal Hocko
2019-01-31 8:03 ` Oscar Salvador
2019-02-12 12:47 ` Jonathan Cameron
2019-02-12 13:21 ` Shameerali Kolothum Thodi
2019-02-12 13:56 ` Oscar Salvador
2019-02-12 14:42 ` Michal Hocko
2019-02-12 14:50 ` Oscar Salvador
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=23d64fa1-386d-bdbf-1546-77eb56fcebc6@redhat.com \
--to=david@redhat.com \
--cc=Pavel.Tatashin@microsoft.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=vkuznets@redhat.com \
/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