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 [li...@arm.linux.org.uk] Sent: Thursday, September 18, 2014 5:59 PM To: Wang, Yalin Cc: Catalin Marinas; Will Deacon; 'linux...@kvack.org'; 'linux-kernel@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org' 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
