From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Alex Ng \(LIS\)" <alexng@microsoft.com>
Cc: "devel\@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
KY Srinivasan <kys@microsoft.com>
Subject: Re: [PATCH 3/4] Drivers: hv: balloon: get rid on ol_waitevent
Date: Thu, 11 Aug 2016 11:18:13 +0200 [thread overview]
Message-ID: <87popf8y0a.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <BN3PR03MB21464E3B83458F6A08DC8861D81D0@BN3PR03MB2146.namprd03.prod.outlook.com> (Alex Ng's message of "Wed, 10 Aug 2016 18:12:05 +0000")
"Alex Ng (LIS)" <alexng@microsoft.com> writes:
>> -----Original Message-----
>> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com]
>> Sent: Friday, August 5, 2016 3:49 AM
>> To: devel@linuxdriverproject.org
>> Cc: linux-kernel@vger.kernel.org; Haiyang Zhang <haiyangz@microsoft.com>; KY
>> Srinivasan <kys@microsoft.com>; Alex Ng (LIS) <alexng@microsoft.com>
>> Subject: [PATCH 3/4] Drivers: hv: balloon: get rid on ol_waitevent
>>
>> With the recently introduced in-kernel memory onlining
>> (MEMORY_HOTPLUG_DEFAULT_ONLINE) these it no point in waiting for pages
>> to come online in the driver and in case the feature is disabled the 5
>> second wait won't help. Get rid of the waiting.
>>
>
> Continuing our internal discussion here. Here's the context.
>
>> > Is it necessary to remove the ol_waitevent in "Drivers: hv: balloon: get rid
>> > on ol_waitevent"? If we respond to the host too quickly, then the next
>> > hot-add request may not see the new pages come online and could fail to
>> > alloc memory as seen in the call trace.
>> >
>> > Thoughts?
>>
>> This should not be an issue with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE: we
>> online pages when we add them (add_memory()) so when we reply to the host
>> these pages are already online. But in case the onlining is done by an
>> external tool (e.g. udev) this wait helps (not always, as if someone eats
>> all memory before the next add_memory call we're still in trouble).
>
> MEMORY_HOTPLUG_DEFAULT_ONLINE is disabled in Kconfig by default.
> Would it make sense to keep the wait and only #ifdef it out when CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is set?
I have a better idea. We can check 'memhp_auto_online' value to see the
current status and don't wait if it is 'true'. Will do v2.
--
Vitaly
next prev parent reply other threads:[~2016-08-11 9:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-05 10:49 [PATCH 0/4] Drivers: hv: balloon: fix WS2012 memory hotplug issues and do some cleanup Vitaly Kuznetsov
2016-08-05 10:49 ` [PATCH 1/4] Drivers: hv: balloon: keep track of where ha_region starts Vitaly Kuznetsov
2016-08-05 10:49 ` [PATCH 2/4] Drivers: hv: balloon: account for gaps in hot add regions Vitaly Kuznetsov
2016-08-06 0:07 ` Alex Ng (LIS)
2016-08-08 9:38 ` Vitaly Kuznetsov
2016-08-05 10:49 ` [PATCH 3/4] Drivers: hv: balloon: get rid on ol_waitevent Vitaly Kuznetsov
2016-08-10 18:12 ` Alex Ng (LIS)
2016-08-11 9:18 ` Vitaly Kuznetsov [this message]
2016-08-05 10:49 ` [PATCH 4/4] Drivers: hv: balloon: replace ha_region_mutex with spinlock Vitaly Kuznetsov
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=87popf8y0a.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=alexng@microsoft.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.