From: David Vrabel <david.vrabel@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Daniel Kiper <daniel.kiper@oracle.com>,
Dan Williams <dan.j.williams@intel.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Xishi Qiu <qiuxishi@huawei.com>,
Mel Gorman <mgorman@techsingularity.net>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Igor Mammedov <imammedo@redhat.com>, Kay Sievers <kay@vrfy.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v3] memory-hotplug: add automatic onlining policy for the newly added memory
Date: Mon, 11 Jan 2016 13:21:53 +0000 [thread overview]
Message-ID: <5693AC71.8080400@citrix.com> (raw)
In-Reply-To: <871t9ojphn.fsf@vitty.brq.redhat.com>
On 11/01/16 11:59, Vitaly Kuznetsov wrote:
> David Vrabel <david.vrabel@citrix.com> writes:
>
>> On 07/01/16 17:23, Vitaly Kuznetsov wrote:
>>>
>>> - Changes since 'v1':
>>> Add 'online' parameter to add_memory_resource() as it is being used by
>>> xen ballon driver and it adds "empty" memory pages [David Vrabel].
>>> (I don't completely understand what prevents manual onlining in this
>>> case as we still have all newly added blocks in sysfs ... this is the
>>> discussion point.)
>>
>
> (there is a discussion with Daniel on the same topic in a parallel
> thread)
>
>> I'm not sure what you're not understanding here?
>>
>> Memory added by the Xen balloon driver (whether populated with real
>> memory or not) does need to be onlined by udev or similar.
>
>
> Yes, same as all other memory hotplug mechanisms (hyper-v's balloon
> driver and acpi memory hotplug). My patch adds an option to make this
> happen automatically. Xen driver is currently excluded because of a
> deadlock. If this deadlock is the only problem we can easily change
> taking the lock to checking that the lock was taken (and taking in case
> it wasn't) or something similar and everything is going to work. From
> briefly looking at the code it seems to me it's going to work.
I don't think Linux has recursive mutex that we could use for this.
> What I wasn't sure about is 'empty pages' you were mentioning. In case
> there are some pages we can't online there should be a protection
> mechanism actively preventing them from going online (similar to
> hv_online_page() in Hyper-V driver) as this patch does nothing
> 'special' compared to udev onlining newly added blocks.
'Empty' (or unpopulated) pages are those without any physical RAM
backing them. Backend drivers map foreign (from other guest) pages into
these unpopulated pages. i.e., accesses by the kernel to the virtual
addresses of these pages access memory shared by another guest.
These empty pages are ones we would prefer to be always automatically
onlined because they're hotplugged in response to requests from the
backend drivers.
Anyway, this series is fine with this Xen balloon driver limitation --
it can be addresses at a later date if necessary.
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2016-01-11 13:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 17:23 Vitaly Kuznetsov
2016-01-08 14:01 ` Daniel Kiper
2016-01-08 16:55 ` Vitaly Kuznetsov
2016-01-11 8:10 ` Daniel Kiper
2016-01-11 12:42 ` Daniel Kiper
2016-01-11 15:03 ` Vitaly Kuznetsov
2016-01-11 16:22 ` Daniel Kiper
2016-01-12 7:44 ` Daniel Kiper
2016-01-11 11:01 ` David Vrabel
2016-01-11 11:59 ` Vitaly Kuznetsov
2016-01-11 13:21 ` David Vrabel [this message]
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=5693AC71.8080400@citrix.com \
--to=david.vrabel@citrix.com \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=daniel.kiper@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=imammedo@redhat.com \
--cc=kay@vrfy.org \
--cc=konrad.wilk@oracle.com \
--cc=kys@microsoft.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=qiuxishi@huawei.com \
--cc=rientjes@google.com \
--cc=tangchen@cn.fujitsu.com \
--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