This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] freeing unused memory

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] freeing unused memory
From: Igor Mammedov <imammedo@xxxxxxxxxx>
Date: Thu, 30 Jun 2011 16:20:13 +0200
Delivery-date: Thu, 30 Jun 2011 07:20:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E0AF620.4060500@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E0AF620.4060500@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Red Hat/3.1.11-2.el6_1 Lightning/1.0b2 Thunderbird/3.1.11
On 06/29/2011 11:53 AM, Igor Mammedov wrote:

I have a question about how upstream patches:

093d7b4639951 xen: release unused free memory
f89e048e76da7 xen: make sure pages are really part of domain before freeing

are supposed to work. Was it intended for freeing unused memory if we boot kernel with mem=XX option and domU is configured with more memory than XX?

In regard to RHBZ#523130, I made additional debugging after applying
above mentioned patches. Result: unsed memory is not freed if we pass
mex=XXXM option to pv guest kernel.

Here is call order:
setup_arch ->
 ->  setup_memory_map
   ->  x86_init.resources.memory_setup == xen_memory_setup
           before xen_return_unused_memory call we have e820 map like this
           that contains all memory provide by xen:
             BIOS-provided physical RAM map:
               Xen: 0000000000000000 - 00000000000a0000 (usable)
               Xen: 00000000000a0000 - 0000000000100000 (reserved)
               Xen: 0000000000100000 - 0000000200000000 (usable
*      ->  xen_return_unused_memory

** ->  parse_early_param

code fragment:
        for (i = 0; i<  e820->nr_map&&  last_end<  max_addr; i++) {
                phys_addr_t end = e820->map[i].addr;
                end = min(max_addr, end);

                released += xen_release_chunk(last_end, end);
                last_end = e820->map[i].addr + e820->map[i].size;
in best case is nop since xen_release_chunk will not do anything if end<=
last_end and with our example map pairs (last_end, end) will look like:
  last_end   end
  0x0        0x0
  0xa0000    0xa0000
  0x100000   0x100000
i.e. last_end == end =>  xen_release_chunk is nop
in worst case xen_release_chunk may try to release not existed gap if e820 is

last fragment of xen_return_unused_memory
        if (last_end<  max_addr)
                released += xen_release_chunk(last_end, max_addr);

has sense only if
   last_end(e820 val)<  max_addr (max hv provided addr)
and that could be only if "mem=" parameter was applied to e820 map.
However ** parse_early_param is called after x86_init.resources.memory_setup in
setup_memory_map. So patches:
093d7b4639951 xen: release unused free memory
f89e048e76da7 xen: make sure pages are really part of domain before freeing
are effectively nop code now.

Problem exist not only in rhel6 code but fc15 as well and I guess upstream
is affected to.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>