From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"'Ian Campbell (Ian.Campbell@citrix.com)'"
<Ian.Campbell@citrix.com>,
"'Jan Beulich (JBeulich@suse.com)'" <JBeulich@suse.com>
Subject: Re: real physical e820 table for dom0?
Date: Thu, 6 Mar 2014 13:45:07 -0500 [thread overview]
Message-ID: <20140306184507.GB9852@localhost.localdomain> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0A9FF00D@SHSMSX104.ccr.corp.intel.com>
On Thu, Mar 06, 2014 at 08:45:35AM +0000, Zhang, Yang Z wrote:
> Hi all,
>
> I have 8G memory in hardware and I only give 2G memory to dom0. The information from /proc/meminfo shows the total memory is about 2G which should be correct. But the memory information from sysrq is wrong (see below). It shows the total memory is 8G(2015427 pages) which I thought should be 2G also. After a little investigation, I found currently dom0 using the real physical e820 map which I remember should be a pseudo-e820 map provided by Xen long time ago.
I am not sure I see the problem. The
>
> Here is my e820 table:
> [ 0.000000] e820: BIOS-provided physical RAM map:
> [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
> [ 0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
> [ 0.000000] Xen: [mem 0x0000000000100000-0x00000000b9775fff] usable
> [ 0.000000] Xen: [mem 0x00000000b9776000-0x00000000b977cfff] ACPI NVS
> [ 0.000000] Xen: [mem 0x00000000b977d000-0x00000000b9bc2fff] usable
> [ 0.000000] Xen: [mem 0x00000000b9bc3000-0x00000000b9fdcfff] reserved
> [ 0.000000] Xen: [mem 0x00000000b9fdd000-0x00000000cc746fff] usable
> [ 0.000000] Xen: [mem 0x00000000cc747000-0x00000000cc94cfff] reserved
> [ 0.000000] Xen: [mem 0x00000000cc94d000-0x00000000cc961fff] ACPI data
> [ 0.000000] Xen: [mem 0x00000000cc962000-0x00000000cce03fff] ACPI NVS
> [ 0.000000] Xen: [mem 0x00000000cce04000-0x00000000cdffefff] reserved
> [ 0.000000] Xen: [mem 0x00000000cdfff000-0x00000000cdffffff] usable
> [ 0.000000] Xen: [mem 0x00000000cf000000-0x00000000df1fffff] reserved
> [ 0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
> [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [ 0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
> [ 0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
> [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
> [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] Xen: [mem 0x0000000100000000-0x000000021fdfffff] usable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] SMBIOS 2.7 present.
> [ 0.000000] DMI: ASUS All Series/Z87-PRO, BIOS 0801 04/19/2013
> [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> [ 0.000000] e820: last_pfn = 0x21fe00 max_arch_pfn = 0x400000000
> [ 0.000000] e820: last_pfn = 0xce000 max_arch_pfn = 0x400000000
>
> Obviously, now dom0 sees the whole physical memory map and the last_pfn is 0x21fe00 which exceed the 2G bound. I wonder why using the real physical memory map? At least now the sysrq is showing wrong output.
>
> Here is the changeset to use the physical E820 table:
>
> commit 9e9a5fcb04e3af077d1be32710298b852210d93f
> Author: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu Sep 2 16:16:00 2010 +0100
>
> xen: use host E820 map for dom0
>
> When running as initial domain, get the real physical memory map from
> xen using the XENMEM_machine_memory_map hypercall and use it to setup
> the e820 regions.
>
> memory info from sysrq:
> [ 97.145517] SysRq : Show Memory
> [ 97.146701] Mem-Info:
> [ 97.147502] DMA per-cpu:
> [ 97.148389] CPU 0: hi: 0, btch: 1 usd: 0
> [ 97.150070] CPU 1: hi: 0, btch: 1 usd: 0
> [ 97.151750] CPU 2: hi: 0, btch: 1 usd: 0
> [ 97.153422] CPU 3: hi: 0, btch: 1 usd: 0
> [ 97.155093] DMA32 per-cpu:
> [ 97.156041] CPU 0: hi: 186, btch: 31 usd: 179
> [ 97.157718] CPU 1: hi: 186, btch: 31 usd: 45
> [ 97.159393] CPU 2: hi: 186, btch: 31 usd: 142
> [ 97.160324] CPU 3: hi: 186, btch: 31 usd: 153
> [ 97.160713] Normal per-cpu:
> [ 97.160940] CPU 0: hi: 0, btch: 1 usd: 0
> [ 97.161326] CPU 1: hi: 0, btch: 1 usd: 0
> [ 97.161715] CPU 2: hi: 0, btch: 1 usd: 0
> [ 97.162103] CPU 3: hi: 0, btch: 1 usd: 0
> [ 97.162492] active_anon:54690 inactive_anon:984 isolated_anon:0
> [ 97.162492] active_file:25003 inactive_file:48300 isolated_file:0
> [ 97.162492] unevictable:2 dirty:323 writeback:0 unstable:0
> [ 97.162492] free:569113 slab_reclaimable:7449 slab_unreclaimable:5467
> [ 97.162492] mapped:15956 shmem:1098 pagetables:10222 bounce:0
> [ 97.162492] free_cma:0
> [ 97.165045] DMA free:12764kB min:36kB low:44kB high:52kB active_anon:1196kB inactive_anon:12kB active_file:516kB inactive_file:860kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15984kB managed:15896kB mlocked:0kB dirty:12kB writeback:0kB mapped:288kB shmem:12kB slab_reclaimable:160kB slab_unreclaimable:72kB kernel_stack:32kB pagetables:220kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [ 97.168243] lowmem_reserve[]: 0 2818 2818 2818
> [ 97.168676] DMA32 free:2263688kB min:6772kB low:8464kB high:10156kB active_anon:217564kB inactive_anon:3924kB active_file:99496kB inactive_file:192340kB unevictable:8kB isolated(anon):0kB isolated(file):0kB present:3329180kB managed:2890396kB mlocked:8kB dirty:1280kB writeback:0kB mapped:63536kB shmem:4380kB slab_reclaimable:29636kB slab_unreclaimable:21796kB kernel_stack:2560kB pagetables:40668kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [ 97.244293] lowmem_reserve[]: 0 0 0 0
> [ 97.270081] Normal free:0kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4716544kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> [ 97.355942] lowmem_reserve[]: 0 0 0 0
> [ 97.384106] DMA: 2*4kB (U) 1*8kB (U) 1*16kB (M) 2*32kB (EM) 2*64kB (EM) 2*128kB (UM) 2*256kB (EM) 1*512kB (E) 3*1024kB (UEM) 2*2048kB (ER) 1*4096kB (M) = 12768kB
> [ 97.414040] DMA32: 132*4kB (UM) 121*8kB (UEM) 71*16kB (UEM) 18*32kB (UEM) 2*64kB (UE) 4*128kB (UE) 2*256kB (U) 3*512kB (U) 1*1024kB (U) 2*2048kB (EM) 550*4096kB (MR) = 2263816kB
> [ 97.444916] Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [ 97.476175] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
> [ 97.508023] 74406 total pagecache pages
> [ 97.539701] 0 pages in swap cache
> [ 97.571126] Swap cache stats: add 0, delete 0, find 0/0
> [ 97.602918] Free swap = 10485756kB
> [ 97.634737] Total swap = 10485756kB
> [ 97.666398] 2015427 pages RAM
> [ 97.697824] 0 pages HighMem/MovableOnly
> [ 97.729134] 1179136 pages reserved
.. output says that 1179136 pages are reserved. Which is true.
If you add the numbers and subtract the reserved pages you should get
the exact amount of pages you booted the initial domain with.
>
> best regards
> yang
>
>
next prev parent reply other threads:[~2014-03-06 18:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 8:45 real physical e820 table for dom0? Zhang, Yang Z
2014-03-06 10:19 ` Gordan Bobic
2014-03-06 18:45 ` Konrad Rzeszutek Wilk [this message]
2014-03-07 1:29 ` Zhang, Yang Z
2014-03-07 13:56 ` Konrad Rzeszutek Wilk
2014-03-10 8:22 ` Zhang, Yang Z
2014-03-10 16:27 ` Konrad Rzeszutek Wilk
2014-03-10 16:39 ` Jan Beulich
2014-03-10 18:37 ` Konrad Rzeszutek Wilk
2014-03-11 10:28 ` David Vrabel
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=20140306184507.GB9852@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
--cc=yang.z.zhang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).