All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.