* Re: x86_64: wrong DirectMap kB
@ 2012-10-01 10:46 Jamie Gloudon
2012-10-01 15:23 ` Hugh Dickins
0 siblings, 1 reply; 6+ messages in thread
From: Jamie Gloudon @ 2012-10-01 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: hughd
Hey,
Interesting. I am able to reproduce the same problem as you using mem=700M, which shows:
DirectMap4k: 4096 kB
DirectMap2M: 18446744073709547520 kB
However, it appears to be normal without the boot parameter:
DirectMap4k: 4096 kB
DirectMap2M: 15708160 kB
What does your output looks like with the full amount on 3.6?
Jamie Gloudon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: x86_64: wrong DirectMap kB
2012-10-01 10:46 x86_64: wrong DirectMap kB Jamie Gloudon
@ 2012-10-01 15:23 ` Hugh Dickins
2012-10-01 15:43 ` Jamie Gloudon
0 siblings, 1 reply; 6+ messages in thread
From: Hugh Dickins @ 2012-10-01 15:23 UTC (permalink / raw)
To: Jamie Gloudon; +Cc: linux-kernel
On Mon, 1 Oct 2012, Jamie Gloudon wrote:
>
> Interesting. I am able to reproduce the same problem as you using mem=700M, which shows:
>
> DirectMap4k: 4096 kB
> DirectMap2M: 18446744073709547520 kB
>
> However, it appears to be normal without the boot parameter:
>
> DirectMap4k: 4096 kB
> DirectMap2M: 15708160 kB
It appears to be normal because the calculations haven't wrapped around,
but if you compare with 3.4 or before, I think you'll find that it
still adds up to too little.
>
> What does your output looks like with the full amount on 3.6?
On 3.6:
MemTotal: 8060528 kB
...
DirectMap4k: 2048 kB
DirectMap2M: 7229440 kB
So it's showing significantly less direct mapped than is included
in MemTotal (which itself omits some areas of reserved memory).
Whereas on 3.4:
MemTotal: 8060760 kB
...
DirectMap4k: 4096 kB
DirectMap2M: 8275968 kB
Hugh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: x86_64: wrong DirectMap kB
2012-10-01 15:23 ` Hugh Dickins
@ 2012-10-01 15:43 ` Jamie Gloudon
0 siblings, 0 replies; 6+ messages in thread
From: Jamie Gloudon @ 2012-10-01 15:43 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linux-kernel
I was also skeptical about DirectMap results added up being less than
MemTotal. I see now, Thanks for the explanation.
Jamie Gloudon
On Mon, Oct 01, 2012 at 08:23:38AM -0700, Hugh Dickins wrote:
> On Mon, 1 Oct 2012, Jamie Gloudon wrote:
> >
> > Interesting. I am able to reproduce the same problem as you using mem=700M, which shows:
> >
> > DirectMap4k: 4096 kB
> > DirectMap2M: 18446744073709547520 kB
> >
> > However, it appears to be normal without the boot parameter:
> >
> > DirectMap4k: 4096 kB
> > DirectMap2M: 15708160 kB
>
> It appears to be normal because the calculations haven't wrapped around,
> but if you compare with 3.4 or before, I think you'll find that it
> still adds up to too little.
>
> >
> > What does your output looks like with the full amount on 3.6?
>
> On 3.6:
>
> MemTotal: 8060528 kB
> ...
> DirectMap4k: 2048 kB
> DirectMap2M: 7229440 kB
>
> So it's showing significantly less direct mapped than is included
> in MemTotal (which itself omits some areas of reserved memory).
>
> Whereas on 3.4:
>
> MemTotal: 8060760 kB
> ...
> DirectMap4k: 4096 kB
> DirectMap2M: 8275968 kB
>
> Hugh
^ permalink raw reply [flat|nested] 6+ messages in thread
* x86_64: wrong DirectMap kB
@ 2012-10-01 8:37 Hugh Dickins
2012-10-02 14:19 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Hugh Dickins @ 2012-10-01 8:37 UTC (permalink / raw)
To: Jan Beulich; +Cc: Yinghai Lu, Andi Kleen, Ingo Molnar, linux-kernel, x86
Jan,
I noticed yesterday that the DirectMap counts at the bottom of x86_64's
/proc/meminfo are wrong on v3.5 and v3.6. For example, I happen to have
booted this laptop with mem=700M to run a test, but /proc/meminfo shows
DirectMap4k: 4096 kB
DirectMap2M: 18446744073709547520 kB
Or if I boot with the full amount of physical memory, the DirectMap
numbers do not add up to the full amount of physical memory, as they
used to do on v3.4 and before.
Whilst I've not yet tried reverting it, I strongly suspect your
20167d3421a0 "x86-64: Fix accounting in kernel_physical_mapping_init()".
Either it was a complete misunderstanding, totally bogus, and should
simply be reverted; or perhaps you really noticed something wrong in
your code inspection, but didn't get the fix quite right?
Hugh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: x86_64: wrong DirectMap kB
2012-10-01 8:37 Hugh Dickins
@ 2012-10-02 14:19 ` Jan Beulich
2012-10-02 18:16 ` Hugh Dickins
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2012-10-02 14:19 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andi Kleen, Ingo Molnar, x86, Yinghai Lu, linux-kernel
>>> On 01.10.12 at 10:37, Hugh Dickins <hughd@google.com> wrote:
> I noticed yesterday that the DirectMap counts at the bottom of x86_64's
> /proc/meminfo are wrong on v3.5 and v3.6. For example, I happen to have
> booted this laptop with mem=700M to run a test, but /proc/meminfo shows
>
> DirectMap4k: 4096 kB
> DirectMap2M: 18446744073709547520 kB
I cannot see such odd effect with "mem="; with I can (for any
value up to around 1G).
> Or if I boot with the full amount of physical memory, the DirectMap
> numbers do not add up to the full amount of physical memory, as they
> used to do on v3.4 and before.
That one I can see how could have happened, in that said patch
went a little too far: Dropping the "pages" increments from
phys_p[um]d_init() is necessary only for the hotplug case (as
otherwise duplicating accounting already done earlier), while
at boot time we would want to do the accounting.
> Whilst I've not yet tried reverting it, I strongly suspect your
> 20167d3421a0 "x86-64: Fix accounting in kernel_physical_mapping_init()".
>
> Either it was a complete misunderstanding, totally bogus, and should
> simply be reverted; or perhaps you really noticed something wrong in
> your code inspection, but didn't get the fix quite right?
The latter, apparently. The patch below should fix both aspects.
Jan
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -386,7 +386,8 @@ phys_pte_init(pte_t *pte_page, unsigned
* these mappings are more intelligent.
*/
if (pte_val(*pte)) {
- pages++;
+ if (!after_bootmem)
+ pages++;
continue;
}
@@ -451,6 +452,8 @@ phys_pmd_init(pmd_t *pmd_page, unsigned
* attributes.
*/
if (page_size_mask & (1 << PG_LEVEL_2M)) {
+ if (!after_bootmem)
+ pages++;
last_map_addr = next;
continue;
}
@@ -526,6 +529,8 @@ phys_pud_init(pud_t *pud_page, unsigned
* attributes.
*/
if (page_size_mask & (1 << PG_LEVEL_1G)) {
+ if (!after_bootmem)
+ pages++;
last_map_addr = next;
continue;
}
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: x86_64: wrong DirectMap kB
2012-10-02 14:19 ` Jan Beulich
@ 2012-10-02 18:16 ` Hugh Dickins
0 siblings, 0 replies; 6+ messages in thread
From: Hugh Dickins @ 2012-10-02 18:16 UTC (permalink / raw)
To: Jan Beulich
Cc: Andi Kleen, Ingo Molnar, x86, Yinghai Lu, Jamie Gloudon,
linux-kernel
On Tue, 2 Oct 2012, Jan Beulich wrote:
> >>> On 01.10.12 at 10:37, Hugh Dickins <hughd@google.com> wrote:
> > I noticed yesterday that the DirectMap counts at the bottom of x86_64's
> > /proc/meminfo are wrong on v3.5 and v3.6. For example, I happen to have
> > booted this laptop with mem=700M to run a test, but /proc/meminfo shows
> >
> > DirectMap4k: 4096 kB
> > DirectMap2M: 18446744073709547520 kB
>
> I cannot see such odd effect with "mem="; with I can (for any
without
> value up to around 1G).
Yes, only with a small "mem=" was my 2M number so low that it actually
wrapped around to look so obviously wrong - I presume once pat came to
carve a piece out of 0.
But even without "mem=" the DirectMap numbers were wrong, adding up
to less than the MemTotal: I did show numbers to make that clearer to
Jamie yesterday, but missed that all but lkml had dropped from the Cc.
>
> > Or if I boot with the full amount of physical memory, the DirectMap
> > numbers do not add up to the full amount of physical memory, as they
> > used to do on v3.4 and before.
>
> That one I can see how could have happened, in that said patch
> went a little too far: Dropping the "pages" increments from
> phys_p[um]d_init() is necessary only for the hotplug case (as
> otherwise duplicating accounting already done earlier), while
> at boot time we would want to do the accounting.
>
> > Whilst I've not yet tried reverting it, I strongly suspect your
> > 20167d3421a0 "x86-64: Fix accounting in kernel_physical_mapping_init()".
> >
> > Either it was a complete misunderstanding, totally bogus, and should
> > simply be reverted; or perhaps you really noticed something wrong in
> > your code inspection, but didn't get the fix quite right?
>
> The latter, apparently. The patch below should fix both aspects.
Thanks, Jan, certainly this patch puts my "mem=700M" DirectMap numbers
back to exactly what I would expect; and without any "mem=", the ~8GB
total of DirectMap4k and DirectMap2M back to what it was with v3.4.
I'm wording it like that because these days I see 2048 kB of 4k instead
of 4096 kB of 4k, but that's most probably due to other differences.
Hugh
>
> Jan
>
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -386,7 +386,8 @@ phys_pte_init(pte_t *pte_page, unsigned
> * these mappings are more intelligent.
> */
> if (pte_val(*pte)) {
> - pages++;
> + if (!after_bootmem)
> + pages++;
> continue;
> }
>
> @@ -451,6 +452,8 @@ phys_pmd_init(pmd_t *pmd_page, unsigned
> * attributes.
> */
> if (page_size_mask & (1 << PG_LEVEL_2M)) {
> + if (!after_bootmem)
> + pages++;
> last_map_addr = next;
> continue;
> }
> @@ -526,6 +529,8 @@ phys_pud_init(pud_t *pud_page, unsigned
> * attributes.
> */
> if (page_size_mask & (1 << PG_LEVEL_1G)) {
> + if (!after_bootmem)
> + pages++;
> last_map_addr = next;
> continue;
> }
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-02 18:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-01 10:46 x86_64: wrong DirectMap kB Jamie Gloudon
2012-10-01 15:23 ` Hugh Dickins
2012-10-01 15:43 ` Jamie Gloudon
-- strict thread matches above, loose matches on Subject: below --
2012-10-01 8:37 Hugh Dickins
2012-10-02 14:19 ` Jan Beulich
2012-10-02 18:16 ` Hugh Dickins
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.