On 2017/3/1 18:41, Jisheng Zhang wrote:
Add Chen, Catalin
On Thu, 16 Feb 2017 09:11:29 +0800 zhouxianrong wrote:
On 2017/2/15 15:10, Ard Biesheuvel wrote:
On 15 February 2017 at 01:44, zhouxianrong wrote:
On 2017/2/14 17:03, Ard Biesheuvel wrote:
On 14 February 2017 at 06:53, <zhouxianrong@xxxxxxxxxx> wrote:
From: zhouxianrong <zhouxianrong@xxxxxxxxxx>
just like freeing no-map area's memmap (gaps of memblock.memory)
we could free reserved area's memmap (areas of memblock.reserved)
as well only when user of reserved area indicate that we can do
this in drivers. that is, user of reserved area know how to
use the reserved area who could not memblock_free or free_reserved_xxx
the reserved area and regard the area as raw pfn usage by kernel.
the patch supply a way to users who want to utilize the memmap
memory corresponding to raw pfn reserved areas as many as possible.
users can do this by memblock_mark_raw_pfn interface which mark the
reserved area as raw pfn and tell free_unused_memmap that this area's
memmap could be freeed.
Could you give an example how much memory we actually recover by doing
this? I understand it depends on the size of the reserved regions, but
I'm sure you have an actual example that inspired you to write this
patch.
i did statistics in our platform, the memmap of reserved region that can be
freed
is about 6MB. it's fewer.
<...>
In any case, it is good to emphasize that on 4 KB pagesize kernels, we
will only free multiples of 8 MB that are 8 MB aligned, resulting in
128 KB of memmap backing to be released.
+ if (start < end)
+ free_memmap(start, end);
+ }
}
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..9f8d277 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -26,6 +26,7 @@ enum {
MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */
MEMBLOCK_MIRROR = 0x2, /* mirrored region */
MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct
mapping */
+ MEMBLOCK_RAW_PFN = 0x8, /* region whose memmap never be
used */
I think we should be *very* careful about the combinatorial explosion
that results when combining all these flags, given that this is not a
proper enum but a bit field.
In any case, the generic memblock change should be in a separate patch
from the arm64 change.
MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP can not be set at the same time
They should not. But if I call memblock_mark_raw_pfn() on a
MEMBLOCK_NOMAP region, it will have both flags set.
In summary, I don't think we need this patch. And if you can convince
us otherwise, you should really be more methodical and explicit in
implementing this RAW_PFN flag, not add it as a byproduct of the arch
code that uses it. Also, you should explain how RAW_PFN relates to
NOMAP, and ensure that RAW_PFN and NOMAP regions don't intersect if
that is an unsupported combination.
yes, setting both MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP could meet some problems
when gaps of memblock.memory intersect memblock.reserved. if they do not intersect,
that's ok. so as you said this should be carefully considered.
as you think this patch is not needed because, i have showed my idea, it's enough, thanks!
we are also interested in this area.
Just curious, is this patch to "free the vmemmap holes" mentioned by
by Catalin in [1]?
free the vmemmap of reserved memblock (other than no-map regions) whose driver owner know
it is never be used.
[1]http://lkml.iu.edu/hypermail/linux/kernel/1604.1/03036.html
.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
