All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Michael Kelley <mikelley@microsoft.com>,
	"lantianyu1986\@gmail.com" <lantianyu1986@gmail.com>,
	KY Srinivasan <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	"sashal\@kernel.org" <sashal@kernel.org>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>,
	"linux-hyperv\@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable\@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH V2] x86/Hyper-V: Balloon up according to request page number
Date: Mon, 20 Jan 2020 11:21:38 +0100	[thread overview]
Message-ID: <87v9p6fmx9.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <MW2PR2101MB10520A27DC77E3B2F15EC75FD7300@MW2PR2101MB1052.namprd21.prod.outlook.com>

Michael Kelley <mikelley@microsoft.com> writes:

> From: Tianyu Lan <Tianyu.Lan@microsoft.com> Sent: Thursday, January 16, 2020 6:16 AM
>> 
>> Current code has assumption that balloon request memory size aligns
>> with 2MB. But actually Hyper-V doesn't guarantee such alignment. When
>> balloon driver receives non-aligned balloon request, it produces warning
>> and balloon up more memory than requested in order to keep 2MB alignment.
>> Remove the warning and balloon up memory according to actual requested
>> memory size.
>> 
>> Fixes: f6712238471a ("hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory
>> block")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
>> ---
>> Change since v2:
>>     - Change logic of switching alloc_unit from 2MB to 4KB
>>     in the balloon_up() to avoid redundant iteration when
>>     handle non-aligned page request.
>>     - Remove 2MB alignment operation and comment in balloon_up()
>> ---
>>  drivers/hv/hv_balloon.c | 12 ++++--------
>>  1 file changed, 4 insertions(+), 8 deletions(-)
>> 
>> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
>> index 7f3e7ab22d5d..536807efbc35 100644
>> --- a/drivers/hv/hv_balloon.c
>> +++ b/drivers/hv/hv_balloon.c
>> @@ -1684,7 +1684,7 @@ static unsigned int alloc_balloon_pages(struct
>> hv_dynmem_device *dm,
>>  	if (num_pages < alloc_unit)
>>  		return 0;
>
> The above test is no longer necessary.  The num_pages < alloc_unit
> case is handled implicitly by your new 'for' loop condition.
>
>> 
>> -	for (i = 0; (i * alloc_unit) < num_pages; i++) {
>> +	for (i = 0; i < num_pages / alloc_unit; i++) {
>>  		if (bl_resp->hdr.size + sizeof(union dm_mem_page_range) >
>>  			HV_HYP_PAGE_SIZE)
>>  			return i * alloc_unit;
>> @@ -1722,7 +1722,7 @@ static unsigned int alloc_balloon_pages(struct
>> hv_dynmem_device *dm,
>> 
>>  	}
>> 
>> -	return num_pages;
>> +	return i * alloc_unit;
>>  }
>> 
>>  static void balloon_up(union dm_msg_info *msg_info)
>> @@ -1737,9 +1737,6 @@ static void balloon_up(union dm_msg_info *msg_info)
>>  	long avail_pages;
>>  	unsigned long floor;
>> 
>> -	/* The host balloons pages in 2M granularity. */
>> -	WARN_ON_ONCE(num_pages % PAGES_IN_2M != 0);
>> -
>>  	/*
>>  	 * We will attempt 2M allocations. However, if we fail to
>>  	 * allocate 2M chunks, we will go back to PAGE_SIZE allocations.
>> @@ -1749,14 +1746,13 @@ static void balloon_up(union dm_msg_info *msg_info)
>>  	avail_pages = si_mem_available();
>>  	floor = compute_balloon_floor();
>> 
>> -	/* Refuse to balloon below the floor, keep the 2M granularity. */
>> +	/* Refuse to balloon below the floor. */
>>  	if (avail_pages < num_pages || avail_pages - num_pages < floor) {
>>  		pr_warn("Balloon request will be partially fulfilled. %s\n",
>>  			avail_pages < num_pages ? "Not enough memory." :
>>  			"Balloon floor reached.");
>> 
>>  		num_pages = avail_pages > floor ? (avail_pages - floor) : 0;
>> -		num_pages -= num_pages % PAGES_IN_2M;
>>  	}
>> 
>>  	while (!done) {
>> @@ -1770,7 +1766,7 @@ static void balloon_up(union dm_msg_info *msg_info)
>>  		num_ballooned = alloc_balloon_pages(&dm_device, num_pages,
>>  						    bl_resp, alloc_unit);
>> 
>> -		if (alloc_unit != 1 && num_ballooned == 0) {
>> +		if (alloc_unit != 1 && num_ballooned != num_pages) {
>
> Maybe I'm missing something, but I don't think Vitaly's optimization works.  If
> alloc_unit specifies 2 Mbytes, and num_pages specifies 3 Mbytes, then num_ballooned
> will come back as 2 Mbytes, which is correct.  But if we revert alloc_unit to 1 page and
> "continue" in that case, we will lose the 2 Mbytes of memory (it's not freed), and the
> next time through the loop will try to allocate only 1 Mbyte (because num_pages
> will be decremented by num_ballooned).  I think the original code does the right thing.
>

True, nice catch! What I meant to say is that we can avoid sending two
replies to the host and get away with just one. Unfortunately,
"num_ballooned != num_pages" modification is not sufficient as
alloc_balloon_pages() will overwrite bl_resp->range_array[] (as it
always starts from 0). I think we can still achieve the goal by
allocating bl_resp outside of the loop and filling it from
range_array[range_count] instead of range_array[i] but it seems to big
of a change for now particular gain. Let's just drop the idea.


> Michael
>
>>  			alloc_unit = 1;
>>  			continue;
>>  		}
>> --
>> 2.14.5
>

-- 
Vitaly


      parent reply	other threads:[~2020-01-20 10:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 14:16 [PATCH V2] x86/Hyper-V: Balloon up according to request page number lantianyu1986
2020-01-16 16:26 ` Vitaly Kuznetsov
2020-01-18 19:29 ` Michael Kelley
2020-01-20  7:56   ` Tianyu Lan
2020-01-20 10:21   ` Vitaly Kuznetsov [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=87v9p6fmx9.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=Tianyu.Lan@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=lantianyu1986@gmail.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=sthemmin@microsoft.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 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.