RE: [PATCH] arm64:free_initrd_mem should also free the memblock

[Wang, Yalin]

hi 

(a)
We have pages which are allocated on demand, which are then marked with
the PG_reserved flag to indicate that they are something special.  These
get counted in the statistics as "reserved" pages.  These pages may be
freed at a later time.  These never appear in memblock.

(b)
We have pages which cover the kernel text/data.  These are never freed
once the system is running.  Memblock records a chunk of memory reserved
at boot time for the kernel, so that memblock does not try to allocate
from that region.
(c)
We also have pages which cover the DT and initrd images.  Again, we need
to mark them reserved in memblock so that it doesn't try to allocate from
those regions while we're bringing the kernel up.  However, once the
kernel is running, these areas are freed into the normal memory kernel
memory allocators, but they remain in memblock.


generically to say, the reserved memory i want to know  means all the physical memory whose
struct page are never placed into buddy system ,
this means memblock.reserve  should include (b) , but not include (a) and (c) .

use debugfs to print all struct page which has  PG_reserved is a good idea .
But there is a little problem here :
the struct page which has PG_reserved set maybe come from (a) or (b) ,
if memblock.reserve also mark both (a) (b) as reserved ,
we will assume it come from (b) , even it come from (a) ,
this is wrong .

but this special case is very rare , should not a serious problem .

i will think of your new idea for reserved memory debug .

Thanks !




________________________________________
From: Russell King - ARM Linux [linux@xxxxxxxxxxxxxxxx]
Sent: Thursday, September 18, 2014 5:59 PM
To: Wang, Yalin
Cc: Catalin Marinas; Will Deacon; 'linux-mm@xxxxxxxxx'; 'linux-kernel@xxxxxxxxxxxxxxx'; 'linux-arm-kernel@xxxxxxxxxxxxxxxxxxx'
Subject: Re: [PATCH] arm64:free_initrd_mem should also free the memblock

On Thu, Sep 18, 2014 at 05:38:54PM +0800, Wang, Yalin wrote:
> Hi Russell,
>
> mm..
> I see your meaning,
> But how to debug reserved memory,
> I mean how to know which physical memory are reserved in kernel if
> Not use /sys/kernel/debug/memblock/reserved  debug file ?

What are you trying to do when you say "debug reserved memory" ?
Let's first sort out what you mean by "reserved memory".

We have pages which are allocated on demand, which are then marked with
the PG_reserved flag to indicate that they are something special.  These
get counted in the statistics as "reserved" pages.  These pages may be
freed at a later time.  These never appear in memblock.

We have pages which cover the kernel text/data.  These are never freed
once the system is running.  Memblock records a chunk of memory reserved
at boot time for the kernel, so that memblock does not try to allocate
from that region.

We also have pages which cover the DT and initrd images.  Again, we need
to mark them reserved in memblock so that it doesn't try to allocate from
those regions while we're bringing the kernel up.  However, once the
kernel is running, these areas are freed into the normal memory kernel
memory allocators, but they remain in memblock.

So, even if you solve the third case, your picture of reserved memory
from memblock is still very much incomplete, and adding memblock calls
to all the sites which allocate and then reserve the pages is (a) going
to add unnecessary overhead, and (b) is going to add quite a bit of
complexity all over the kernel.

Let me re-iterate.  memblock is a stepping stone for bringing the kernel
up.  It is used early in boot to provide trivial memory allocation, and
once the main kernel memory allocators are initialised (using allocations
from memblock), memblock becomes mostly redundant - memblocks idea of
reserved areas becomes completely redundant and unnecessary since that
information is now tracked by the main kernel allocators.

It's useful to leave memblock reserved memory in place, because then you
have a picture at early kernel boot which you can then compare with the
page arrays, and see what's changed between early boot and the current
kernels state.  Yes, there is no code to dump out the page array - when
you realise that dumping the page array (which is 262144 entries per
gigabyte of memory) in some generic way becomes quite cumbersome.  The
array itself is around 8MB per gigabyte of memory.

If you want this information, it's probably best to write a custom debugfs
entry which scans the page array, and dumps the regions of reserved memory
(in other words, detects where the PG_reserved flag changes state between
two consecutive pages.)

With such a dump, you can then compare it with the memblock reserved
debugfs file, and check whether the initrd was properly freed, etc.  If
you dump it in the same format as the memblock reserved debugfs, you
can compare the two using diff(1).

The other advantage of this approach is that you're not asking lots of
places in the kernel to gain additional calls to change the state of
something that is never otherwise used.

--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/