Skip to contentSkip to conversation

mm/memblock: print memblock_remove

PATCH In review Minchan Kim 2 participants 4 messages May 8, 2018 – May 9, 2018

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mm/memblock: print memblock_remove

memblock_remove report is useful to see why MemTotal of /proc/meminfo between two kernels makes difference.

---
 mm/memblock.c | 5 +++++
 1 file changed, 5 insertions(+)
mm/memblock.c +5 -0
index 5228f594b13c..03d48d8835ba 100644
@@ -697,6 +697,11 @@ static int __init_memblock memblock_remove_range(struct memblock_type *type,
 
 int __init_memblock memblock_remove(phys_addr_t base, phys_addr_t size)
 {
+	phys_addr_t end = base + size - 1;
+
+	memblock_dbg("memblock_remove: [%pa-%pa] %pS\n",
+		     &base, &end, (void *)_RET_IP_);
+
 	return memblock_remove_range(&memblock.memory, base, size);
 }
 
Signature · 1 line
2.17.0.441.gb46fe60e1d-goog
#1 lore raw
Quoted 13 lines · Minchan Kim

memblock_remove report is useful to see why MemTotal of /proc/meminfo between two kernels makes difference.

---
 mm/memblock.c | 5 +++++
 1 file changed, 5 insertions(+)
mm/memblock.c +0 -0
index 5228f594b13c..03d48d8835ba 100644

mm/memblock.c static int __init_memblock memblock_remove_range(struct memblock_type *type, · line 703

Quoted 7 lines
mm/memblock.c +4 -0
@@ -697,6 +697,11 @@ static int __init_memblock memblock_remove_range(struct memblock_type *type,
 
 int __init_memblock memblock_remove(phys_addr_t base, phys_addr_t size)
 {
+	phys_addr_t end = base + size - 1;
+
+	memblock_dbg("memblock_remove: [%pa-%pa] %pS\n",
+		     &base, &end, (void *)_RET_IP_);

Other callers of memblock_dbg use %pF. Is there any reason to be different here?

Other that that looks ok to me.

Signature · 2 lines
Michal Hocko
SUSE Labs
#2 lore raw
Quoted 15 lines · Michal Hocko
Quoted 14 lines · Minchan Kim

memblock_remove report is useful to see why MemTotal of /proc/meminfo between two kernels makes difference.

---
 mm/memblock.c | 5 +++++
 1 file changed, 5 insertions(+)
mm/memblock.c +0 -0
index 5228f594b13c..03d48d8835ba 100644
@@ -697,6 +697,11 @@ static int __init_memblock memblock_remove_range(struct memblock_type *type,
 
Quoted 9 lines

mm/memblock.c static int __init_memblock memblock_remove_range(struct memblock_type *type, · line 703

Quoted 6 lines
mm/memblock.c +4 -0
 int __init_memblock memblock_remove(phys_addr_t base, phys_addr_t size)
 {
+	phys_addr_t end = base + size - 1;
+
+	memblock_dbg("memblock_remove: [%pa-%pa] %pS\n",
+		     &base, &end, (void *)_RET_IP_);

Other callers of memblock_dbg use %pF. Is there any reason to be different here?

checkpatch hit me.

WARNING: Deprecated vsprintf pointer extension '%pF' - use %pS instead #24: FILE: mm/memblock.c:702:
+ memblock_dbg("memblock_remove: [%pa-%pa] %pF\n",
+ &base, &end, (void *)_RET_IP_);

Quoted 2 lines

Other that that looks ok to me.

Thanks, Michal.

Acked-by
#3 lore raw
Quoted 30 lines · Minchan Kim
Quoted 15 lines · Michal Hocko
Quoted 14 lines · Minchan Kim

memblock_remove report is useful to see why MemTotal of /proc/meminfo between two kernels makes difference.

---
 mm/memblock.c | 5 +++++
 1 file changed, 5 insertions(+)
mm/memblock.c +0 -0
index 5228f594b13c..03d48d8835ba 100644
@@ -697,6 +697,11 @@ static int __init_memblock memblock_remove_range(struct memblock_type *type,
 
Quoted 9 lines

mm/memblock.c static int __init_memblock memblock_remove_range(struct memblock_type *type, · line 703

Quoted 6 lines
mm/memblock.c +4 -0
 int __init_memblock memblock_remove(phys_addr_t base, phys_addr_t size)
 {
+	phys_addr_t end = base + size - 1;
+
+	memblock_dbg("memblock_remove: [%pa-%pa] %pS\n",
+		     &base, &end, (void *)_RET_IP_);

Other callers of memblock_dbg use %pF. Is there any reason to be different here?

checkpatch hit me.

WARNING: Deprecated vsprintf pointer extension '%pF' - use %pS instead #24: FILE: mm/memblock.c:702:

Review

Quoted 2 lines
(quoted diff) +2 -0
+       memblock_dbg("memblock_remove: [%pa-%pa] %pF\n",
+                    &base, &end, (void *)_RET_IP_);

OK, I see. Then we probably need some mass replacement as well. Anyway

for this one.

Signature · 2 lines
Michal Hocko
SUSE Labs