All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting
Date: Fri, 4 Sep 2015 09:47:12 +0200	[thread overview]
Message-ID: <55E94C80.4050706@suse.com> (raw)
In-Reply-To: <55E94A2C.4070900@citrix.com>

On 09/04/2015 09:37 AM, Roger Pau Monné wrote:
> Hello,
>
> El 04/09/15 a les 7.07, Juergen Gross ha escrit:
>> Could you try the attached patch? It should do the job. It is booting
>> fine on my laptop, but I think you should try it on the machine with
>> the memory ranges not at page boundary.
>>
>>
>> Juergen
>>
>>
>> extramem.patch
>>
>>
>> commit 3d0f8aa4d1b4c9c16a81902a197b5d6a77e182a0
>> Author: Juergen Gross <jgross@suse.com>
>> Date:   Thu Sep 3 17:44:04 2015 +0200
>>
>>      xen: switch extra memory accounting to use pfns
>>
>>      Instead of using physical addresses for accounting of extra memory
>>      areas available for ballooning switch to pfns as this is much less
>>      error prone regarding partial pages.
>
> Thanks for taking care of this! I've tested it on the box that has
> non-page aligned memory ranges and it works fine, only a couple of
> comments below.
>
>>      Reported-by: Roger Pau Monné <roger.pau@citrix.com>
>>      Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 7a5d566..aa58bc4 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -90,62 +90,65 @@ static void __init xen_parse_512gb(void)
>>   	xen_512gb_limit = val;
>>   }
>>
>> -static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
>> +static void __init xen_add_extra_mem(unsigned long start_pfn,
>> +				     unsigned long n_pfns)
>
> Not very important, but for type consistency this should probably be
> xen_pfn_t instead of unsigned long here and below.

All of the p2m code is using unsigned long for pfns. I wouldn't mind
changing this to use xen_pfn_t instead, but this should be done in a
separate patch. I'll put it on my list.

>
>>   {
>>   	int i;
>>
>>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>>   		/* Add new region. */
>> -		if (xen_extra_mem[i].size == 0) {
>> -			xen_extra_mem[i].start = start;
>> -			xen_extra_mem[i].size  = size;
>> +		if (xen_extra_mem[i].n_pfns == 0) {
>> +			xen_extra_mem[i].start_pfn = start_pfn;
>> +			xen_extra_mem[i].n_pfns = n_pfns;
>>   			break;
>>   		}
>>   		/* Append to existing region. */
>> -		if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) {
>> -			xen_extra_mem[i].size += size;
>> +		if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
>> +		    start_pfn) {
>> +			xen_extra_mem[i].n_pfns += n_pfns;
>>   			break;
>>   		}
>
> I also noticed this with the original code, why isn't there a case to
> prepend to an existing region:
>
> if (start_pfn + n_pfns == xen_extra_mem[i].start_pfn) {
>      xen_extra_mem[i].n_pfns += n_pfns;
>      xen_extra_mem[i].start_pfn = start_pfn;
> }

Processing of memory is done from low to high addresses. This case
should never happen. And even if it does, the only downside from
not handling this scenario is wasting an additional table entry.

>
>>   	}
>>   	if (i == XEN_EXTRA_MEM_MAX_REGIONS)
>>   		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>>
>> -	memblock_reserve(start, size);
>> +	memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
>>   }
>
> [...]
>
>> @@ -831,9 +833,11 @@ char * __init xen_memory_setup(void)
>>   				chunk_size = min(size, mem_end - addr);
>>   			} else if (extra_pages) {
>>   				chunk_size = min(size, PFN_PHYS(extra_pages));
>> -				extra_pages -= PFN_DOWN(chunk_size);
>> -				xen_add_extra_mem(addr, chunk_size);
>> -				xen_max_p2m_pfn = PFN_DOWN(addr + chunk_size);
>> +				pfn_s = PFN_UP(addr);
>> +				n_pfns = PFN_DOWN(addr + chunk_size) - pfn_s;
>
> Should xen_add_extra_mem check for empty ranges and bail out early, or
> should the caller make sure it doesn't try to add empty ranges?
>
> IMHO it's easier and cleaner to add the check to xen_add_extra_mem.

This isn't critical at all. Adding an empty range is a nop, as a table
entry is regarded to be not used when n_pfns is 0.


Juergen


  parent reply	other threads:[~2015-09-04  7:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03 12:05 [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monne
2015-09-03 12:15 ` Roger Pau Monné
2015-09-03 12:15 ` Roger Pau Monné
2015-09-03 12:26   ` Juergen Gross
2015-09-03 12:26   ` Juergen Gross
2015-09-03 12:25 ` Juergen Gross
2015-09-03 14:38   ` Roger Pau Monné
2015-09-03 14:45     ` David Vrabel
2015-09-03 14:45     ` David Vrabel
2015-09-03 14:52       ` David Vrabel
2015-09-03 14:52       ` [Xen-devel] " David Vrabel
2015-09-03 14:55         ` Juergen Gross
2015-09-03 14:55         ` [Xen-devel] " Juergen Gross
2015-09-03 15:01           ` David Vrabel
2015-09-03 15:20             ` Juergen Gross
2015-09-03 15:20             ` [Xen-devel] " Juergen Gross
2015-09-03 15:39               ` Roger Pau Monné
2015-09-03 15:39               ` [Xen-devel] " Roger Pau Monné
2015-09-03 15:46                 ` Juergen Gross
2015-09-03 15:46                   ` Juergen Gross
2015-09-04  5:07                 ` Juergen Gross
2015-09-04  5:07                 ` [Xen-devel] " Juergen Gross
2015-09-04  7:37                   ` Roger Pau Monné
2015-09-04  7:37                   ` [Xen-devel] " Roger Pau Monné
2015-09-04  7:47                     ` Juergen Gross
2015-09-04  7:47                     ` Juergen Gross [this message]
2015-09-04  7:57                       ` Roger Pau Monné
2015-09-04  7:57                       ` [Xen-devel] " Roger Pau Monné
2015-09-04  8:07                         ` Juergen Gross
2015-09-04  8:07                         ` [Xen-devel] " Juergen Gross
2015-09-03 15:01           ` David Vrabel
2015-09-03 14:50     ` Juergen Gross
2015-09-03 14:50     ` Juergen Gross
2015-09-03 14:38   ` Roger Pau Monné
2015-09-03 12:25 ` Juergen Gross

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=55E94C80.4050706@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.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.