From: Igor Mammedov <imammedo@redhat.com>
To: xen-devel@lists.xensource.com
Subject: Re: freeing unused memory
Date: Thu, 30 Jun 2011 16:20:13 +0200 [thread overview]
Message-ID: <4E0C861D.6090005@redhat.com> (raw)
In-Reply-To: <4E0AF620.4060500@redhat.com>
On 06/29/2011 11:53 AM, Igor Mammedov wrote:
> Hi,
>
> 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:
@xen_return_unused_memory
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
sparse.
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.
--
Thanks,
Igor
next prev parent reply other threads:[~2011-06-30 14:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-29 9:53 freeing unused memory Igor Mammedov
2011-06-30 14:20 ` Igor Mammedov [this message]
2011-07-22 13:48 ` Konrad Rzeszutek Wilk
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=4E0C861D.6090005@redhat.com \
--to=imammedo@redhat.com \
--cc=xen-devel@lists.xensource.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.