* real physical e820 table for dom0?
@ 2014-03-06 8:45 Zhang, Yang Z
2014-03-06 10:19 ` Gordan Bobic
2014-03-06 18:45 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 10+ messages in thread
From: Zhang, Yang Z @ 2014-03-06 8:45 UTC (permalink / raw)
To: xen-devel
Cc: 'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.com)'
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.
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
best regards
yang
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
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
1 sibling, 0 replies; 10+ messages in thread
From: Gordan Bobic @ 2014-03-06 10:19 UTC (permalink / raw)
To: xen-devel
I was under the impression that dom0 should always have the
real e820 map. If you limit it's memory, the memory gets
truncated at the point where that much real RAM is allocated,
but the reserved areas and holes should remain as per the
physical map.
Is that not what is expected?
Gordan
On 2014-03-06 08:45, 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.
>
> 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
>
> best regards
> yang
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
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
2014-03-07 1:29 ` Zhang, Yang Z
1 sibling, 1 reply; 10+ messages in thread
From: Konrad Rzeszutek Wilk @ 2014-03-06 18:45 UTC (permalink / raw)
To: Zhang, Yang Z
Cc: xen-devel, 'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.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
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
2014-03-06 18:45 ` Konrad Rzeszutek Wilk
@ 2014-03-07 1:29 ` Zhang, Yang Z
2014-03-07 13:56 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 10+ messages in thread
From: Zhang, Yang Z @ 2014-03-07 1:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, 'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.com)'
Konrad Rzeszutek Wilk wrote on 2014-03-07:
> 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.
Yes. It is correct if subtracting the reserved pages. But the problem is why dom0 will see it? Per my understanding, it ok to expose the real e820 table to dom0, but the total memory dom0 saw should be identical to the number Xen gave to it. Just like we add 'mem=' parameter in dom0's cmdline.
Here is an example is if adding mem=1G in dom0's boot line, we can see the page number is exact 262044 not whole 2015427.
[ 111.125949] Swap cache stats: add 0, delete 0, find 0/0
[ 111.125955] Free swap = 10485756kB
[ 111.125959] Total swap = 10485756kB
[ 111.125964] 262044 pages RAM
[ 111.125969] 0 pages HighMem/MovableOnly
[ 111.125973] 26041 pages reserved
>
>>
>> best regards
>> yang
>>
>>
Best regards,
Yang
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
2014-03-07 1:29 ` Zhang, Yang Z
@ 2014-03-07 13:56 ` Konrad Rzeszutek Wilk
2014-03-10 8:22 ` Zhang, Yang Z
0 siblings, 1 reply; 10+ messages in thread
From: Konrad Rzeszutek Wilk @ 2014-03-07 13:56 UTC (permalink / raw)
To: Zhang, Yang Z
Cc: xen-devel, 'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.com)'
On Fri, Mar 07, 2014 at 01:29:31AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-03-07:
> > 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.
>
> Yes. It is correct if subtracting the reserved pages. But the problem is why dom0 will see it? Per my understanding, it ok to expose the real e820 table to dom0, but the total memory dom0 saw should be identical to the number Xen gave to it. Just like we add 'mem=' parameter in dom0's cmdline.
>
> Here is an example is if adding mem=1G in dom0's boot line, we can see the page number is exact 262044 not whole 2015427.
> [ 111.125949] Swap cache stats: add 0, delete 0, find 0/0
> [ 111.125955] Free swap = 10485756kB
> [ 111.125959] Total swap = 10485756kB
> [ 111.125964] 262044 pages RAM
> [ 111.125969] 0 pages HighMem/MovableOnly
> [ 111.125973] 26041 pages reserved
>
How do you use the dom0_mem_max= argument? And what version of Xen are you using?
There was this patch:
commit d3db728125c4470a2d061ac10fa7395e18237263
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed Dec 14 12:16:08 2011 +0000
xen: only limit memory map to maximum reservation for domain 0.
d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
clamped the total amount of RAM to the current maximum reservation. This is
correct for dom0 but is not correct for guest domains. In order to boot a guest
Perhaps you don't have it in the hypervisor?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
2014-03-07 13:56 ` Konrad Rzeszutek Wilk
@ 2014-03-10 8:22 ` Zhang, Yang Z
2014-03-10 16:27 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 10+ messages in thread
From: Zhang, Yang Z @ 2014-03-10 8:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, 'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.com)'
Konrad Rzeszutek Wilk wrote on 2014-03-07:
> On Fri, Mar 07, 2014 at 01:29:31AM +0000, Zhang, Yang Z wrote:
>
> How do you use the dom0_mem_max= argument? And what version of Xen are
> you using?
>
I tried it both in Xen and dom0, no help. But adding "dom0_mem=4096M,max:4096M" to xen cmdline helps.
I am using the latest Xen upstream.
> There was this patch:
>
> commit d3db728125c4470a2d061ac10fa7395e18237263
> Author: Ian Campbell <Ian.Campbell@citrix.com>
> Date: Wed Dec 14 12:16:08 2011 +0000
>
> xen: only limit memory map to maximum reservation for domain 0.
>
> d312ae878b6a "xen: use maximum reservation to limit amount of usable
> RAM" clamped the total amount of RAM to the current maximum
> reservation. This is correct for dom0 but is not correct for guest
> domains. In order to
> boot a guest
>
> Perhaps you don't have it in the hypervisor?
Hypervisor? I find the patch in dom0.
Best regards,
Yang
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
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-11 10:28 ` David Vrabel
0 siblings, 2 replies; 10+ messages in thread
From: Konrad Rzeszutek Wilk @ 2014-03-10 16:27 UTC (permalink / raw)
To: Zhang, Yang Z
Cc: xen-devel, 'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.com)'
On Mon, Mar 10, 2014 at 08:22:48AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-03-07:
> > On Fri, Mar 07, 2014 at 01:29:31AM +0000, Zhang, Yang Z wrote:
> >
> > How do you use the dom0_mem_max= argument? And what version of Xen are
> > you using?
> >
>
> I tried it both in Xen and dom0, no help. But adding "dom0_mem=4096M,max:4096M" to xen cmdline helps.
> I am using the latest Xen upstream.
Right. That is how it is suppose to work. What did you have before?
dom0_mem=4G?
That means it will boot with all the memory that Xen sees and balloon down to 4GB.
See http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
>
> > There was this patch:
> >
> > commit d3db728125c4470a2d061ac10fa7395e18237263
> > Author: Ian Campbell <Ian.Campbell@citrix.com>
> > Date: Wed Dec 14 12:16:08 2011 +0000
> >
> > xen: only limit memory map to maximum reservation for domain 0.
> >
> > d312ae878b6a "xen: use maximum reservation to limit amount of usable
> > RAM" clamped the total amount of RAM to the current maximum
> > reservation. This is correct for dom0 but is not correct for guest
> > domains. In order to
> > boot a guest
> >
> > Perhaps you don't have it in the hypervisor?
>
> Hypervisor? I find the patch in dom0.
In the commit it says: d312ae878b6a "xen: use maximum reservation to limit amount of usable.."
That is the hypervisor one.
>
> Best regards,
> Yang
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
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
1 sibling, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2014-03-10 16:39 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Yang Z Zhang, xen-devel,
'Ian Campbell (Ian.Campbell@citrix.com)'
>>> On 10.03.14 at 17:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Mar 10, 2014 at 08:22:48AM +0000, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-03-07:
>> > On Fri, Mar 07, 2014 at 01:29:31AM +0000, Zhang, Yang Z wrote:
>> >
>> > How do you use the dom0_mem_max= argument? And what version of Xen are
>> > you using?
>> >
>>
>> I tried it both in Xen and dom0, no help. But adding
> "dom0_mem=4096M,max:4096M" to xen cmdline helps.
>> I am using the latest Xen upstream.
>
> Right. That is how it is suppose to work. What did you have before?
> dom0_mem=4G?
>
> That means it will boot with all the memory that Xen sees and balloon down
> to 4GB.
Since when?
Jan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
2014-03-10 16:39 ` Jan Beulich
@ 2014-03-10 18:37 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 10+ messages in thread
From: Konrad Rzeszutek Wilk @ 2014-03-10 18:37 UTC (permalink / raw)
To: Jan Beulich
Cc: Yang Z Zhang, xen-devel,
'Ian Campbell (Ian.Campbell@citrix.com)'
On Mon, Mar 10, 2014 at 04:39:13PM +0000, Jan Beulich wrote:
> >>> On 10.03.14 at 17:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Mon, Mar 10, 2014 at 08:22:48AM +0000, Zhang, Yang Z wrote:
> >> Konrad Rzeszutek Wilk wrote on 2014-03-07:
> >> > On Fri, Mar 07, 2014 at 01:29:31AM +0000, Zhang, Yang Z wrote:
> >> >
> >> > How do you use the dom0_mem_max= argument? And what version of Xen are
> >> > you using?
> >> >
> >>
> >> I tried it both in Xen and dom0, no help. But adding
> > "dom0_mem=4096M,max:4096M" to xen cmdline helps.
> >> I am using the latest Xen upstream.
> >
> > Right. That is how it is suppose to work. What did you have before?
> > dom0_mem=4G?
> >
> > That means it will boot with all the memory that Xen sees and balloon down
> > to 4GB.
>
> Since when?
I was thinking this would be it:
8f370c14acf1c326a5e0ab8c505414600ff3c0
Author: David Vrabel <david.vrabel@citrix.com>
Date: Mon Aug 22 10:05:27 2011 +0100
x86: use 'dom0_mem' to limit the number of pages for dom0
Use the 'dom0_mem' command line option to set the maximum number of
pages for dom0. dom0 can use then use the XENMEM_maximum_reservation
memory op to automatically find this limit and reduce the size of any
page tables etc.
But now that I look at the code, I see that if you specific
dom0_mem=4G it will boot with 4GB and no more.
And the Linux kernel should be able to work with that.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: real physical e820 table for dom0?
2014-03-10 16:27 ` Konrad Rzeszutek Wilk
2014-03-10 16:39 ` Jan Beulich
@ 2014-03-11 10:28 ` David Vrabel
1 sibling, 0 replies; 10+ messages in thread
From: David Vrabel @ 2014-03-11 10:28 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Zhang, Yang Z, xen-devel,
'Ian Campbell (Ian.Campbell@citrix.com)',
'Jan Beulich (JBeulich@suse.com)'
On 10/03/14 16:27, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 10, 2014 at 08:22:48AM +0000, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-03-07:
>>> On Fri, Mar 07, 2014 at 01:29:31AM +0000, Zhang, Yang Z wrote:
>>>
>>> How do you use the dom0_mem_max= argument? And what version of Xen are
>>> you using?
>>>
>>
>> I tried it both in Xen and dom0, no help. But adding "dom0_mem=4096M,max:4096M" to xen cmdline helps.
>> I am using the latest Xen upstream.
>
> Right. That is how it is suppose to work. What did you have before?
> dom0_mem=4G?
>
> That means it will boot with all the memory that Xen sees and balloon down to 4GB.
No, it starts with 4 GB and sets the maximum reservation to all of RAM
(allowing dom0 to balloon up).
David
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-03-11 10:28 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.