[0/2] vmalloc: Add /proc/vmallocinfo to display mappings

Christoph Lameter

author

2008-03-18 22:27 UTC #0 lore raw

cover vmalloc: Add /proc/vmallocinfo to display mappings

The following two patches implement /proc/vmallocinfo. /proc/vmallocinfo displays data about the vmalloc allocations. The second patch introduces a tracing feature that allows to display the function that allocated the vmalloc area.

Example:

cat /proc/vmallocinfo

0xffffc20000000000-0xffffc20000801000 8392704 alloc_large_system_hash+0x127/0x246 pages=2048 vmalloc vpages
0xffffc20000801000-0xffffc20000806000 20480 alloc_large_system_hash+0x127/0x246 pages=4 vmalloc
0xffffc20000806000-0xffffc20000c07000 4198400 alloc_large_system_hash+0x127/0x246 pages=1024 vmalloc vpages
0xffffc20000c07000-0xffffc20000c0a000 12288 alloc_large_system_hash+0x127/0x246 pages=2 vmalloc
0xffffc20000c0a000-0xffffc20000c0c000 8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c0c000-0xffffc20000c0f000 12288 acpi_os_map_memory+0x13/0x1c phys=cff64000 ioremap
0xffffc20000c10000-0xffffc20000c15000 20480 acpi_os_map_memory+0x13/0x1c phys=cff65000 ioremap

0xffffc20000c16000-0xffffc20000c18000    8192 acpi_os_map_memory+0x13/0x1c phys=cff69000 ioremap
0xffffc20000c18000-0xffffc20000c1a000    8192 acpi_os_map_memory+0x13/0x1c phys=fed1f000 ioremap
0xffffc20000c1a000-0xffffc20000c1c000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c1c000-0xffffc20000c1e000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c1e000-0xffffc20000c20000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c20000-0xffffc20000c22000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c22000-0xffffc20000c24000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c24000-0xffffc20000c26000    8192 acpi_os_map_memory+0x13/0x1c phys=e0081000 ioremap
0xffffc20000c26000-0xffffc20000c28000    8192 acpi_os_map_memory+0x13/0x1c phys=e0080000 ioremap
0xffffc20000c28000-0xffffc20000c2d000   20480 alloc_large_system_hash+0x127/0x246 pages=4 vmalloc
0xffffc20000c2d000-0xffffc20000c31000   16384 tcp_init+0xd5/0x31c pages=3 vmalloc
0xffffc20000c31000-0xffffc20000c34000   12288 alloc_large_system_hash+0x127/0x246 pages=2 vmalloc
0xffffc20000c34000-0xffffc20000c36000    8192 init_vdso_vars+0xde/0x1f1
0xffffc20000c36000-0xffffc20000c38000    8192 pci_iomap+0x8a/0xb4 phys=d8e00000 ioremap
0xffffc20000c38000-0xffffc20000c3a000    8192 usb_hcd_pci_probe+0x139/0x295 [usbcore] phys=d8e00000 ioremap
0xffffc20000c3a000-0xffffc20000c3e000   16384 sys_swapon+0x509/0xa15 pages=3 vmalloc
0xffffc20000c40000-0xffffc20000c61000  135168 e1000_probe+0x1c4/0xa32 phys=d8a20000 ioremap
0xffffc20000c61000-0xffffc20000c6a000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c6a000-0xffffc20000c73000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c73000-0xffffc20000c7c000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c7c000-0xffffc20000c7f000   12288 e1000e_setup_tx_resources+0x29/0xbe pages=2 vmalloc

0xffffc20000c80000-0xffffc20001481000 8392704 pci_mmcfg_arch_init+0x90/0x118 phys=e0000000 ioremap 0xffffc20001481000-0xffffc20001682000 2101248 alloc_large_system_hash+0x127/0x246 pages=512 vmalloc 0xffffc20001682000-0xffffc20001e83000 8392704 alloc_large_system_hash+0x127/0x246 pages=2048 vmalloc vpages 0xffffc20001e83000-0xffffc20002204000 3674112 alloc_large_system_hash+0x127/0x246 pages=896 vmalloc vpages

0xffffc20002204000-0xffffc2000220d000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc2000220d000-0xffffc20002216000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002216000-0xffffc2000221f000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc2000221f000-0xffffc20002228000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002228000-0xffffc20002231000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002231000-0xffffc20002234000   12288 e1000e_setup_rx_resources+0x35/0x122 pages=2 vmalloc
0xffffc20002240000-0xffffc20002261000  135168 e1000_probe+0x1c4/0xa32 phys=d8a60000 ioremap
0xffffc20002261000-0xffffc2000270c000 4894720 sys_swapon+0x509/0xa15 pages=1194 vmalloc vpages
0xffffffffa0000000-0xffffffffa0022000  139264 module_alloc+0x4f/0x55 pages=33 vmalloc
0xffffffffa0022000-0xffffffffa0029000   28672 module_alloc+0x4f/0x55 pages=6 vmalloc
0xffffffffa002b000-0xffffffffa0034000   36864 module_alloc+0x4f/0x55 pages=8 vmalloc
0xffffffffa0034000-0xffffffffa003d000   36864 module_alloc+0x4f/0x55 pages=8 vmalloc
0xffffffffa003d000-0xffffffffa0049000   49152 module_alloc+0x4f/0x55 pages=11 vmalloc
0xffffffffa0049000-0xffffffffa0050000   28672 module_alloc+0x4f/0x55 pages=6 vmalloc

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-18 22:27 UTC #1 lore raw

PATCH 1/2 vmalloc: Show vmalloced areas via /proc/vmallocinfo

Implement a new proc file that allows the display of the currently allocated vmalloc memory.

Signed-off-by Christoph Lameter <[email protected]>

---
 fs/proc/proc_misc.c     |   14 ++++++++
 include/linux/vmalloc.h |    2 +
 mm/vmalloc.c            |   76 +++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 91 insertions(+), 1 deletion(-)

fs/proc/proc_misc.c +14 -0

Index: linux-2.6.25-rc5-mm1/fs/proc/proc_misc.c
===================================================================
@@ -456,6 +456,18 @@ static const struct file_operations proc
 #endif
 #endif
 
+static int vmalloc_open(struct inode *inode, struct file *file)
+{
+	return seq_open(file, &vmalloc_op);
+}
+
+static const struct file_operations proc_vmalloc_operations = {
+	.open		= vmalloc_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
 static int show_stat(struct seq_file *p, void *v)
 {
 	int i;

@@ -990,6 +1002,8 @@ void __init proc_misc_init(void)
 	proc_create("slab_allocators", 0, NULL, &proc_slabstats_operations);
 #endif
 #endif
+	proc_create("vmallocinfo",S_IWUSR|S_IRUGO, NULL,
+						&proc_vmalloc_operations);
 	proc_create("buddyinfo", S_IRUGO, NULL, &fragmentation_file_operations);
 	proc_create("pagetypeinfo", S_IRUGO, NULL, &pagetypeinfo_file_ops);
 	proc_create("vmstat", S_IRUGO, NULL, &proc_vmstat_file_operations);

include/linux/vmalloc.h +2 -0

Index: linux-2.6.25-rc5-mm1/include/linux/vmalloc.h
===================================================================
@@ -87,4 +87,6 @@ extern void free_vm_area(struct vm_struc
 extern rwlock_t vmlist_lock;
 extern struct vm_struct *vmlist;
 
+extern const struct seq_operations vmalloc_op;
+
 #endif /* _LINUX_VMALLOC_H */

mm/vmalloc.c +75 -1

85 lines not on this page · raw message

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arjan van de Ven

2008-03-20 04:04 UTC #2 lore raw

Re: [1/2] vmalloc: Show vmalloced areas via /proc/vmallocinfo

fs/proc/proc_misc.c void __init proc_misc_init(void) · line 1005

Quoted 4 lines · On Tue, 18 Mar 2008 15:27:02 -0700 Christoph Lameter <[email protected]> wrote:

Implement a new proc file that allows the display of the currently allocated vmalloc memory.
fs/proc/proc_misc.c +1 -0
+	proc_create("vmallocinfo",S_IWUSR|S_IRUGO, NULL,

why should non-root be able to read this? sounds like a security issue (info leak) to me...

Signature · 9 lines

If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-20 19:22 UTC #3 lore raw

Re: [1/2] vmalloc: Show vmalloced areas via /proc/vmallocinfo

Quoted 2 lines · Arjan van de Ven

Review
Quoted 1 line
(quoted diff) +1 -0
+	proc_create("vmallocinfo",S_IWUSR|S_IRUGO, NULL,
why should non-root be able to read this? sounds like a security issue (info leak) to me...

Well I copied from the slabinfo logic (leaking info for slabs is okay?).

Lets restrict it to root then:

Subject: vmallocinfo: Only allow root to read /proc/vmallocinfo

Change permissions for /proc/vmallocinfo to only allow read for root.

Signed-off-by Christoph Lameter <[email protected]>

---
 fs/proc/proc_misc.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

fs/proc/proc_misc.c +1 -2

Index: linux-2.6.25-rc5-mm1/fs/proc/proc_misc.c
===================================================================
@@ -1002,8 +1002,7 @@ void __init proc_misc_init(void)
 	proc_create("slab_allocators", 0, NULL, &proc_slabstats_operations);
 #endif
 #endif
-	proc_create("vmallocinfo",S_IWUSR|S_IRUGO, NULL,
-						&proc_vmalloc_operations);
+	proc_create("vmallocinfo",S_IRUSR, NULL, &proc_vmalloc_operations);
 	proc_create("buddyinfo", S_IRUGO, NULL, &fragmentation_file_operations);
 	proc_create("pagetypeinfo", S_IRUGO, NULL, &pagetypeinfo_file_ops);
 	proc_create("vmstat", S_IRUGO, NULL, &proc_vmstat_file_operations);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrew Morton

maintainer

2008-03-21 22:19 UTC #4 lore raw

Re: [1/2] vmalloc: Show vmalloced areas via /proc/vmallocinfo

Quoted 4 lines · On Thu, 20 Mar 2008 12:22:07 -0700 (PDT) Christoph Lameter <[email protected]>…

Quoted 2 lines · Arjan van de Ven
Review
Quoted 1 line
(quoted diff) +1 -0
+	proc_create("vmallocinfo",S_IWUSR|S_IRUGO, NULL,
why should non-root be able to read this? sounds like a security issue (info leak) to me...

What is the security concern here? This objection is rather vague.

Quoted 10 lines

Well I copied from the slabinfo logic (leaking info for slabs is okay?).
Lets restrict it to root then:
Subject: vmallocinfo: Only allow root to read /proc/vmallocinfo
Change permissions for /proc/vmallocinfo to only allow read for root.

That makes the feature somewhat less useful. Let's think this through more carefully - it is, after all, an unrevokable, unalterable addition to the kernel ABI.

Arjan, what scenarios are you thinking about?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Alan Cox

2008-03-21 22:09 UTC #5 lore raw

Re: [1/2] vmalloc: Show vmalloced areas via /proc/vmallocinfo

Quoted 3 lines

That makes the feature somewhat less useful. Let's think this through more carefully - it is, after all, an unrevokable, unalterable addition to the kernel ABI.

Which means it does not belong in /proc.

Alan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-18 22:27 UTC #6 lore raw

PATCH 2/2 vmallocinfo: Add caller information

In reply to Christoph Lameter

Add caller information so that /proc/vmallocinfo shows where the allocation request for a slice of vmalloc memory originated.

Result in output like this:

0xffffc20000000000-0xffffc20000801000 8392704 alloc_large_system_hash+0x127/0x246 pages=2048 vmalloc vpages
0xffffc20000801000-0xffffc20000806000 20480 alloc_large_system_hash+0x127/0x246 pages=4 vmalloc
0xffffc20000806000-0xffffc20000c07000 4198400 alloc_large_system_hash+0x127/0x246 pages=1024 vmalloc vpages
0xffffc20000c07000-0xffffc20000c0a000 12288 alloc_large_system_hash+0x127/0x246 pages=2 vmalloc
0xffffc20000c0a000-0xffffc20000c0c000 8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c0c000-0xffffc20000c0f000 12288 acpi_os_map_memory+0x13/0x1c phys=cff64000 ioremap
0xffffc20000c10000-0xffffc20000c15000 20480 acpi_os_map_memory+0x13/0x1c phys=cff65000 ioremap

0xffffc20000c16000-0xffffc20000c18000    8192 acpi_os_map_memory+0x13/0x1c phys=cff69000 ioremap
0xffffc20000c18000-0xffffc20000c1a000    8192 acpi_os_map_memory+0x13/0x1c phys=fed1f000 ioremap
0xffffc20000c1a000-0xffffc20000c1c000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c1c000-0xffffc20000c1e000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c1e000-0xffffc20000c20000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c20000-0xffffc20000c22000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c22000-0xffffc20000c24000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c24000-0xffffc20000c26000    8192 acpi_os_map_memory+0x13/0x1c phys=e0081000 ioremap
0xffffc20000c26000-0xffffc20000c28000    8192 acpi_os_map_memory+0x13/0x1c phys=e0080000 ioremap
0xffffc20000c28000-0xffffc20000c2d000   20480 alloc_large_system_hash+0x127/0x246 pages=4 vmalloc
0xffffc20000c2d000-0xffffc20000c31000   16384 tcp_init+0xd5/0x31c pages=3 vmalloc
0xffffc20000c31000-0xffffc20000c34000   12288 alloc_large_system_hash+0x127/0x246 pages=2 vmalloc
0xffffc20000c34000-0xffffc20000c36000    8192 init_vdso_vars+0xde/0x1f1
0xffffc20000c36000-0xffffc20000c38000    8192 pci_iomap+0x8a/0xb4 phys=d8e00000 ioremap
0xffffc20000c38000-0xffffc20000c3a000    8192 usb_hcd_pci_probe+0x139/0x295 [usbcore] phys=d8e00000 ioremap
0xffffc20000c3a000-0xffffc20000c3e000   16384 sys_swapon+0x509/0xa15 pages=3 vmalloc
0xffffc20000c40000-0xffffc20000c61000  135168 e1000_probe+0x1c4/0xa32 phys=d8a20000 ioremap
0xffffc20000c61000-0xffffc20000c6a000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c6a000-0xffffc20000c73000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c73000-0xffffc20000c7c000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c7c000-0xffffc20000c7f000   12288 e1000e_setup_tx_resources+0x29/0xbe pages=2 vmalloc

0xffffc20000c80000-0xffffc20001481000 8392704 pci_mmcfg_arch_init+0x90/0x118 phys=e0000000 ioremap 0xffffc20001481000-0xffffc20001682000 2101248 alloc_large_system_hash+0x127/0x246 pages=512 vmalloc 0xffffc20001682000-0xffffc20001e83000 8392704 alloc_large_system_hash+0x127/0x246 pages=2048 vmalloc vpages 0xffffc20001e83000-0xffffc20002204000 3674112 alloc_large_system_hash+0x127/0x246 pages=896 vmalloc vpages

0xffffc20002204000-0xffffc2000220d000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc2000220d000-0xffffc20002216000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002216000-0xffffc2000221f000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc2000221f000-0xffffc20002228000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002228000-0xffffc20002231000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002231000-0xffffc20002234000   12288 e1000e_setup_rx_resources+0x35/0x122 pages=2 vmalloc
0xffffc20002240000-0xffffc20002261000  135168 e1000_probe+0x1c4/0xa32 phys=d8a60000 ioremap
0xffffc20002261000-0xffffc2000270c000 4894720 sys_swapon+0x509/0xa15 pages=1194 vmalloc vpages
0xffffffffa0000000-0xffffffffa0022000  139264 module_alloc+0x4f/0x55 pages=33 vmalloc
0xffffffffa0022000-0xffffffffa0029000   28672 module_alloc+0x4f/0x55 pages=6 vmalloc
0xffffffffa002b000-0xffffffffa0034000   36864 module_alloc+0x4f/0x55 pages=8 vmalloc
0xffffffffa0034000-0xffffffffa003d000   36864 module_alloc+0x4f/0x55 pages=8 vmalloc
0xffffffffa003d000-0xffffffffa0049000   49152 module_alloc+0x4f/0x55 pages=11 vmalloc
0xffffffffa0049000-0xffffffffa0050000   28672 module_alloc+0x4f/0x55 pages=6 vmalloc

Signed-off-by Christoph Lameter <[email protected]>

---
 arch/x86/mm/ioremap.c   |   12 +++++----
 include/linux/vmalloc.h |    3 ++
 mm/vmalloc.c            |   61 +++++++++++++++++++++++++++++++++++-------------
 3 files changed, 55 insertions(+), 21 deletions(-)

include/linux/vmalloc.h +3 -0

Index: linux-2.6.25-rc5-mm1/include/linux/vmalloc.h
===================================================================
@@ -31,6 +31,7 @@ struct vm_struct {
 	struct page		**pages;
 	unsigned int		nr_pages;
 	unsigned long		phys_addr;
+	void			*caller;
 };
 
 /*

@@ -66,6 +67,8 @@ static inline size_t get_vm_area_size(co
 }
 
 extern struct vm_struct *get_vm_area(unsigned long size, unsigned long flags);
+extern struct vm_struct *get_vm_area_caller(unsigned long size,
+					unsigned long flags, void *caller);
 extern struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
 					unsigned long start, unsigned long end);
 extern struct vm_struct *get_vm_area_node(unsigned long size,

mm/vmalloc.c +45 ~~-16~~

178 lines not on this page · raw message

arch/x86/mm/ioremap.c +7 -5

Index: linux-2.6.25-rc5-mm1/arch/x86/mm/ioremap.c
===================================================================
@@ -118,8 +118,8 @@ static int ioremap_change_attr(unsigned 
  * have to convert them into an offset in a page-aligned mapping, but the
  * caller shouldn't need to know that small detail.
  */
-static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
-			       enum ioremap_mode mode)
+static void __iomem *__ioremap_caller(unsigned long phys_addr,
+	unsigned long size, enum ioremap_mode mode, void *caller)
 {
 	unsigned long pfn, offset, last_addr, vaddr;
 	struct vm_struct *area;

@@ -176,7 +176,7 @@ static void __iomem *__ioremap(unsigned 
 	/*
 	 * Ok, go for it..
 	 */
-	area = get_vm_area(size, VM_IOREMAP);
+	area = get_vm_area_caller(size, VM_IOREMAP, caller);
 	if (!area)
 		return NULL;
 	area->phys_addr = phys_addr;

@@ -217,13 +217,15 @@ static void __iomem *__ioremap(unsigned 
  */
 void __iomem *ioremap_nocache(unsigned long phys_addr, unsigned long size)
 {
-	return __ioremap(phys_addr, size, IOR_MODE_UNCACHED);
+	return __ioremap_caller(phys_addr, size, IOR_MODE_UNCACHED,
+						__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_nocache);
 
 void __iomem *ioremap_cache(unsigned long phys_addr, unsigned long size)
 {
-	return __ioremap(phys_addr, size, IOR_MODE_CACHED);
+	return __ioremap_caller(phys_addr, size, IOR_MODE_CACHED,
+						__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_cache);

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2008-03-19 21:42 UTC #7 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 2 lines · Christoph Lameter

Add caller information so that /proc/vmallocinfo shows where the allocation request for a slice of vmalloc memory originated.

please use one simple save_stack_trace() instead of polluting a dozen architectures with:

arch/x86/mm/ioremap.c static void __iomem *__ioremap(unsigned · line 221

Quoted 3 lines

arch/x86/mm/ioremap.c +2 -1

-	return __ioremap(phys_addr, size, IOR_MODE_UNCACHED);
+	return __ioremap_caller(phys_addr, size, IOR_MODE_UNCACHED,
+						__builtin_return_address(0));

Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-20 00:03 UTC #8 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 8 lines · Ingo Molnar

Quoted 2 lines · Christoph Lameter
Add caller information so that /proc/vmallocinfo shows where the allocation request for a slice of vmalloc memory originated.
please use one simple save_stack_trace() instead of polluting a dozen architectures with:

save_stack_trace() depends on CONFIG_STACKTRACE which is only available when debugging is compiled it. I was more thinking about this as a generally available feature.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2008-03-21 11:00 UTC #9 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 8 lines · Christoph Lameter

Quoted 6 lines · Ingo Molnar
Quoted 2 lines · Christoph Lameter
Add caller information so that /proc/vmallocinfo shows where the allocation request for a slice of vmalloc memory originated.

Quoted 6 lines

Quoted 2 lines
please use one simple save_stack_trace() instead of polluting a dozen architectures with:
save_stack_trace() depends on CONFIG_STACKTRACE which is only available when debugging is compiled it. I was more thinking about this as a generally available feature.

then make STACKTRACE available generally via the patch below.

Ingo

------------------------------------------->
Subject: debugging: always enable stacktrace
From: Ingo Molnar <[email protected]>
Date: Fri Mar 21 11:48:32 CET 2008

Signed-off-by Ingo Molnar <[email protected]>

---
 lib/Kconfig.debug |    1 -
 1 file changed, 1 deletion(-)

lib/Kconfig.debug +0 -1

Index: linux-x86.q/lib/Kconfig.debug
===================================================================
@@ -387,7 +387,6 @@ config DEBUG_LOCKING_API_SELFTESTS
 
 config STACKTRACE
 	bool
-	depends on DEBUG_KERNEL
 	depends on STACKTRACE_SUPPORT
 
 config DEBUG_KOBJECT

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-21 17:35 UTC #10 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 1 line · Ingo Molnar

then make STACKTRACE available generally via the patch below.

How do I figure out which nesting level to display if we'd do this?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2008-03-21 18:45 UTC #11 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 5 lines · Christoph Lameter

Quoted 1 line · Ingo Molnar
then make STACKTRACE available generally via the patch below.
How do I figure out which nesting level to display if we'd do this?

the best i found for lockdep was to include a fair number of them, and to skip the top 3. struct vm_area that vmalloc uses isnt space-critical, so 4-8 entries with a 3 skip would be quite ok. (but can be more than that as well)

Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-21 19:16 UTC #12 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 4 lines · Ingo Molnar

the best i found for lockdep was to include a fair number of them, and to skip the top 3. struct vm_area that vmalloc uses isnt space-critical, so 4-8 entries with a 3 skip would be quite ok. (but can be more than that as well)

STACKTRACE depends on STACKTRACE_SUPPORT which is not available on all arches? alpha blackfin ia64 etc are missing it?

I thought there were also issues on x86 with optimizations leading to weird stacktraces?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2008-03-21 20:55 UTC #13 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 7 lines · Christoph Lameter

Quoted 4 lines
the best i found for lockdep was to include a fair number of them, and to skip the top 3. struct vm_area that vmalloc uses isnt space-critical, so 4-8 entries with a 3 skip would be quite ok. (but can be more than that as well)
STACKTRACE depends on STACKTRACE_SUPPORT which is not available on all arches? alpha blackfin ia64 etc are missing it?

one more reason for them to implement it.

Quoted 2 lines

I thought there were also issues on x86 with optimizations leading to weird stacktraces?

at most there can be extra stack trace entries. This is for debugging, so if someone wants exact stacktraces, FRAME_POINTERS will certainly improve them.

Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Mike Frysinger

2008-03-22 02:40 UTC #14 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 10 lines · Ingo Molnar

Quoted 7 lines · Christoph Lameter
Quoted 4 lines
the best i found for lockdep was to include a fair number of them, and to skip the top 3. struct vm_area that vmalloc uses isnt space-critical, so 4-8 entries with a 3 skip would be quite ok. (but can be more than that as well)
STACKTRACE depends on STACKTRACE_SUPPORT which is not available on all arches? alpha blackfin ia64 etc are missing it?
one more reason for them to implement it.

as long as the new code in question is properly ifdef-ed, making it rely on STACKTRACE sounds fine. i'll open an item in our Blackfin tracker to add support for it.
-mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2008-04-29 08:48 UTC #15 lore raw

Re: [2/2] vmallocinfo: Add caller information

In reply to Christoph Lameter

Quoted 2 lines · Christoph Lameter

Add caller information so that /proc/vmallocinfo shows where the allocation request for a slice of vmalloc memory originated.

i _specifically_ objected to the uglification that this patch brings with itself to the modified arch/x86 files (see the diff excerpt below), in:

    http://lkml.org/lkml/2008/3/19/450

i pointed out how it should be done _much cleaner_ (and much smaller - only a single patch needed) via stack-trace, without changing a dozen architectures, and even gave a patch to make it all easier for you:

    http://lkml.org/lkml/2008/3/19/568
    http://lkml.org/lkml/2008/3/21/88

in fact, a stacktrace printout is much more informative as well to users, than a punny __builtin_return_address(0)!

but you did not reply to my objections in substance, hence i considered the issue closed - but you apparently went ahead without addressing my concerns (which are rather obvious to anyone doing debug code) and now this ugly code is upstream.

If lockdep can get stacktrace samples from all around the kernel without adding "caller" info parameters to widely used APIs, then the MM is evidently able to do it too. _Saving_ a stacktrace is relatively fast [printing it to the console is what is slow], and vmalloc() is an utter slowpath anyway [and 1 million file descriptors does not count as a fastpath].

If performance is of any concern then make it dependent on CONFIG_DEBUG_VM or whatever debug switch in the MM - that will be _faster_ in the default case than the current pass-parameter-deep-down-the-arch crap you've pushed here. I dont remember the last time i genuinely needed the allocation site of a vmalloc().

I any case, do _NOT_ pollute any architectures with stack debugging hacks (and that holds for future similar patches too), that's why we wrote stacktrace. This needs to be reverted or fixed properly.

Ingo

Quoted 31 lines

Index: linux-2.6.25-rc5-mm1/arch/x86/mm/ioremap.c
===================================================================

arch/x86/mm/ioremap.c +5 -4

@@ -118,8 +118,8 @@ static int ioremap_change_attr(unsigned 
  * have to convert them into an offset in a page-aligned mapping, but the
  * caller shouldn't need to know that small detail.
  */
-static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
-			       enum ioremap_mode mode)
+static void __iomem *__ioremap_caller(unsigned long phys_addr,
+	unsigned long size, enum ioremap_mode mode, void *caller)
 {
 	unsigned long pfn, offset, last_addr, vaddr;
 	struct vm_struct *area;

@@ -176,7 +176,7 @@ static void __iomem *__ioremap(unsigned 
 	/*
 	 * Ok, go for it..
 	 */
-	area = get_vm_area(size, VM_IOREMAP);
+	area = get_vm_area_caller(size, VM_IOREMAP, caller);
 	if (!area)
 		return NULL;
 	area->phys_addr = phys_addr;

@@ -217,13 +217,15 @@ static void __iomem *__ioremap(unsigned 
  */
 void __iomem *ioremap_nocache(unsigned long phys_addr, unsigned long size)
 {
-	return __ioremap(phys_addr, size, IOR_MODE_UNCACHED);
+	return __ioremap_caller(phys_addr, size, IOR_MODE_UNCACHED,
+						__builtin_return_address(0));

arch/x86/mm/ioremap.c static void __iomem *__ioremap(unsigned · line 230

Quoted 10 lines

arch/x86/mm/ioremap.c +2 -1

 }
 EXPORT_SYMBOL(ioremap_nocache);
 
 void __iomem *ioremap_cache(unsigned long phys_addr, unsigned long size)
 {
-	return __ioremap(phys_addr, size, IOR_MODE_CACHED);
+	return __ioremap_caller(phys_addr, size, IOR_MODE_CACHED,
+						__builtin_return_address(0));
 }
 EXPORT_SYMBOL(ioremap_cache);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-04-29 17:08 UTC #16 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 9 lines · Ingo Molnar

i pointed out how it should be done _much cleaner_ (and much smaller - only a single patch needed) via stack-trace, without changing a dozen architectures, and even gave a patch to make it all easier for you:
    http://lkml.org/lkml/2008/3/19/568
    http://lkml.org/lkml/2008/3/21/88
in fact, a stacktrace printout is much more informative as well to users, than a punny __builtin_return_address(0)!

Sorry lost track of this issue. Adding stracktrace support is not a trivial thing and will change the basic handling of vmallocinfo.

Not sure if stacktrace support can be enabled without a penalty on various platforms. Doesnt this require stackframes to be formatted in a certain way?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arjan van de Ven

2008-04-28 19:48 UTC #17 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 13 lines · On Tue, 29 Apr 2008 10:08:29 -0700 (PDT) Christoph Lameter <[email protected]>…

Quoted 10 lines · Ingo Molnar
i pointed out how it should be done _much cleaner_ (and much smaller - only a single patch needed) via stack-trace, without changing a dozen architectures, and even gave a patch to make it all easier for you:
    http://lkml.org/lkml/2008/3/19/568
    http://lkml.org/lkml/2008/3/21/88
in fact, a stacktrace printout is much more informative as well to users, than a punny __builtin_return_address(0)!

Quoted 6 lines

Sorry lost track of this issue. Adding stracktrace support is not a trivial thing and will change the basic handling of vmallocinfo.
Not sure if stacktrace support can be enabled without a penalty on various platforms. Doesnt this require stackframes to be formatted in a certain way?

it doesn't.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-04-29 18:49 UTC #18 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 8 lines · Arjan van de Ven

Quoted 6 lines
Sorry lost track of this issue. Adding stracktrace support is not a trivial thing and will change the basic handling of vmallocinfo.
Not sure if stacktrace support can be enabled without a penalty on various platforms. Doesnt this require stackframes to be formatted in a certain way?
it doesn't.

Hmmm... Why do we have CONFIG_FRAMEPOINTER then?

The current implementation of vmalloc_caller() follows what we have done with kmalloc_track_caller. Its low overhead and always on.

It would be great if we could have stacktrace support both for kmalloc and vmalloc in the same way also with low overhead but I think following a backtrace requires much more than simply storing the caller address. A mechanism like that would require an explicit kernel CONFIG option. A year or so ago we had patches to implement stacktraces in the slab allocators but they were not merged due to various arch specific issues with backtraces.

We could dump the offending x86_64 pieces. Some detail of what /proc/vmallocinfo would be lost then.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arjan van de Ven

2008-04-28 21:00 UTC #19 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 5 lines · On Tue, 29 Apr 2008 11:49:54 -0700 (PDT) Christoph Lameter <[email protected]>…

Quoted 3 lines · Arjan van de Ven
Quoted 3 lines
Sorry lost track of this issue. Adding stracktrace support is not a trivial thing and will change the basic handling of vmallocinfo.

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
Not sure if stacktrace support can be enabled without a penalty on various platforms. Doesnt this require stackframes to be formatted in a certain way?
it doesn't.
Hmmm... Why do we have CONFIG_FRAMEPOINTER then?

to make the backtraces more accurate.

Quoted 2 lines

The current implementation of vmalloc_caller() follows what we have done with kmalloc_track_caller. Its low overhead and always on.

stacktraces aren't entirely free, the cost is O(nr of modules) unfortunately ;(

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-04-29 19:09 UTC #20 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 3 lines · Arjan van de Ven

Quoted 1 line
Hmmm... Why do we have CONFIG_FRAMEPOINTER then?
to make the backtraces more accurate.

Well so we display out of whack backtraces? There are also issues on platforms that do not have a stack in the classic sense (rotating register file on IA64 and Sparc64 f.e.). Determining a backtrace can be very expensive.

Quoted 4 lines

Quoted 2 lines
The current implementation of vmalloc_caller() follows what we have done with kmalloc_track_caller. Its low overhead and always on.
stacktraces aren't entirely free, the cost is O(nr of modules) unfortunately ;(

The current implementation /proc/vmallocinfo avoids these issues and with just one caller address it can print one line per vmalloc request.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Pekka Enberg

2008-04-29 19:23 UTC #21 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 4 lines · Christoph Lameter

Well so we display out of whack backtraces? There are also issues on platforms that do not have a stack in the classic sense (rotating register file on IA64 and Sparc64 f.e.). Determining a backtrace can be very expensive.

I think that's the key question here whether we need to enable this on production systems? If yes, why? If it's just a debugging aid, then I see Ingo's point of save_stack_trace(); otherwise the low-overhead __builtin_return_address() makes more sense.

And btw, why is this new file not in /sys/kernel....?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Pekka Enberg

2008-04-29 19:29 UTC #22 lore raw

Re: [2/2] vmallocinfo: Add caller information

Quoted 4 lines · Christoph Lameter

Quoted 4 lines
Well so we display out of whack backtraces? There are also issues on platforms that do not have a stack in the classic sense (rotating register file on IA64 and Sparc64 f.e.). Determining a backtrace can be very expensive.

Quoted 4 lines · Pekka Enberg

I think that's the key question here whether we need to enable this on production systems? If yes, why? If it's just a debugging aid, then I see Ingo's point of save_stack_trace(); otherwise the low-overhead __builtin_return_address() makes more sense.

Actually, this is vmalloc() so why do we even care? If there are callers in the tree that use vmalloc() for performance sensitive stuff, they ought to be converted to kmalloc() anyway, no?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2008-04-29 19:29 UTC #23 lore raw

Re: [2/2] vmallocinfo: Add caller information

In reply to Christoph Lameter

Quoted 10 lines · Christoph Lameter

Quoted 3 lines · Arjan van de Ven
Quoted 1 line
Hmmm... Why do we have CONFIG_FRAMEPOINTER then?
to make the backtraces more accurate.
Well so we display out of whack backtraces? There are also issues on platforms that do not have a stack in the classic sense (rotating register file on IA64 and Sparc64 f.e.). Determining a backtrace can be very expensive.

they have to solve that for kernel oopses and for lockdep somehow anyway. Other users of stacktrace are: fault injection, kmemcheck, latencytop, ftrace. All new debugging and instrumentation code uses it, and for a good reason.

Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

KOSAKI Motohiro

Reviewed-by on the v1 series

2008-03-19 02:23 UTC #24 lore raw

In reply to Christoph Lameter

Hi

Great.
it seems very useful.
and, I found no bug.

Reviewed-by KOSAKI Motohiro <[email protected]>

Quoted 41 lines

The following two patches implement /proc/vmallocinfo. /proc/vmallocinfo displays data about the vmalloc allocations. The second patch introduces a tracing feature that allows to display the function that allocated the vmalloc area.
Example:
cat /proc/vmallocinfo
0xffffc20000000000-0xffffc20000801000 8392704 alloc_large_system_hash+0x127/0x246 pages=2048 vmalloc vpages
0xffffc20000801000-0xffffc20000806000 20480 alloc_large_system_hash+0x127/0x246 pages=4 vmalloc
0xffffc20000806000-0xffffc20000c07000 4198400 alloc_large_system_hash+0x127/0x246 pages=1024 vmalloc vpages
0xffffc20000c07000-0xffffc20000c0a000 12288 alloc_large_system_hash+0x127/0x246 pages=2 vmalloc
0xffffc20000c0a000-0xffffc20000c0c000 8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c0c000-0xffffc20000c0f000 12288 acpi_os_map_memory+0x13/0x1c phys=cff64000 ioremap
0xffffc20000c10000-0xffffc20000c15000 20480 acpi_os_map_memory+0x13/0x1c phys=cff65000 ioremap
0xffffc20000c16000-0xffffc20000c18000    8192 acpi_os_map_memory+0x13/0x1c phys=cff69000 ioremap
0xffffc20000c18000-0xffffc20000c1a000    8192 acpi_os_map_memory+0x13/0x1c phys=fed1f000 ioremap
0xffffc20000c1a000-0xffffc20000c1c000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c1c000-0xffffc20000c1e000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c1e000-0xffffc20000c20000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c20000-0xffffc20000c22000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c22000-0xffffc20000c24000    8192 acpi_os_map_memory+0x13/0x1c phys=cff68000 ioremap
0xffffc20000c24000-0xffffc20000c26000    8192 acpi_os_map_memory+0x13/0x1c phys=e0081000 ioremap
0xffffc20000c26000-0xffffc20000c28000    8192 acpi_os_map_memory+0x13/0x1c phys=e0080000 ioremap
0xffffc20000c28000-0xffffc20000c2d000   20480 alloc_large_system_hash+0x127/0x246 pages=4 vmalloc
0xffffc20000c2d000-0xffffc20000c31000   16384 tcp_init+0xd5/0x31c pages=3 vmalloc
0xffffc20000c31000-0xffffc20000c34000   12288 alloc_large_system_hash+0x127/0x246 pages=2 vmalloc
0xffffc20000c34000-0xffffc20000c36000    8192 init_vdso_vars+0xde/0x1f1
0xffffc20000c36000-0xffffc20000c38000    8192 pci_iomap+0x8a/0xb4 phys=d8e00000 ioremap
0xffffc20000c38000-0xffffc20000c3a000    8192 usb_hcd_pci_probe+0x139/0x295 [usbcore] phys=d8e00000 ioremap
0xffffc20000c3a000-0xffffc20000c3e000   16384 sys_swapon+0x509/0xa15 pages=3 vmalloc
0xffffc20000c40000-0xffffc20000c61000  135168 e1000_probe+0x1c4/0xa32 phys=d8a20000 ioremap
0xffffc20000c61000-0xffffc20000c6a000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c6a000-0xffffc20000c73000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c73000-0xffffc20000c7c000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20000c7c000-0xffffc20000c7f000   12288 e1000e_setup_tx_resources+0x29/0xbe pages=2 vmalloc
0xffffc20000c80000-0xffffc20001481000 8392704 pci_mmcfg_arch_init+0x90/0x118 phys=e0000000 ioremap 0xffffc20001481000-0xffffc20001682000 2101248 alloc_large_system_hash+0x127/0x246 pages=512 vmalloc 0xffffc20001682000-0xffffc20001e83000 8392704 alloc_large_system_hash+0x127/0x246 pages=2048 vmalloc vpages 0xffffc20001e83000-0xffffc20002204000 3674112 alloc_large_system_hash+0x127/0x246 pages=896 vmalloc vpages

Quoted 14 lines

0xffffc20002204000-0xffffc2000220d000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc2000220d000-0xffffc20002216000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002216000-0xffffc2000221f000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc2000221f000-0xffffc20002228000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002228000-0xffffc20002231000   36864 _xfs_buf_map_pages+0x8e/0xc0 vmap
0xffffc20002231000-0xffffc20002234000   12288 e1000e_setup_rx_resources+0x35/0x122 pages=2 vmalloc
0xffffc20002240000-0xffffc20002261000  135168 e1000_probe+0x1c4/0xa32 phys=d8a60000 ioremap
0xffffc20002261000-0xffffc2000270c000 4894720 sys_swapon+0x509/0xa15 pages=1194 vmalloc vpages
0xffffffffa0000000-0xffffffffa0022000  139264 module_alloc+0x4f/0x55 pages=33 vmalloc
0xffffffffa0022000-0xffffffffa0029000   28672 module_alloc+0x4f/0x55 pages=6 vmalloc
0xffffffffa002b000-0xffffffffa0034000   36864 module_alloc+0x4f/0x55 pages=8 vmalloc
0xffffffffa0034000-0xffffffffa003d000   36864 module_alloc+0x4f/0x55 pages=8 vmalloc
0xffffffffa003d000-0xffffffffa0049000   49152 module_alloc+0x4f/0x55 pages=11 vmalloc
0xffffffffa0049000-0xffffffffa0050000   28672 module_alloc+0x4f/0x55 pages=6 vmalloc

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrew Morton

maintainer

2008-03-19 22:07 UTC #25 lore raw

Quoted 9 lines · On Wed, 19 Mar 2008 11:23:30 +0900 KOSAKI Motohiro…

Quoted 9 lines
The following two patches implement /proc/vmallocinfo. /proc/vmallocinfo displays data about the vmalloc allocations. The second patch introduces a tracing feature that allows to display the function that allocated the vmalloc area.
Example:
cat /proc/vmallocinfo

argh, please don't top-post.

(undoes it)

Quoted 8 lines

Hi
Great.
it seems very useful.
and, I found no bug.
Reviewed-by KOSAKI Motohiro <[email protected]>

I was just about to ask whether we actually need the feature - I don't recall ever having needed it, nor do I recall seeing anyone else need it.

Why is it useful?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

author

2008-03-19 23:33 UTC #26 lore raw

Quoted 4 lines · Andrew Morton

I was just about to ask whether we actually need the feature - I don't recall ever having needed it, nor do I recall seeing anyone else need it.
Why is it useful?

It allows to see the users of vmalloc. That is important if vmalloc space is scarce (i386 for example).

And its going to be important for the compound page fallback to vmalloc. Many of the current users can be switched to use compound pages with fallback. This means that the number of users of vmalloc is reduced and page tables no longer necessary to access the memory. /proc/vmallocinfo allows to review how that reduction occurs.

If memory becomes fragmented and larger order allocations are no longer possible then /proc/vmallocinfo allows to see which compound page allocations fell back to virtual compound pages. That is important for new users of virtual compound pages. Such as order 1 stack allocation etc that may fallback to virtual compound pages in the future.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

KOSAKI Motohiro

2008-03-20 07:43 UTC #27 lore raw

In reply to Andrew Morton

Hi Andrew,

Quoted 7 lines

Quoted 3 lines
Quoted 3 lines
Example:
cat /proc/vmallocinfo
argh, please don't top-post.
(undoes it)

sorry, I don't do that at next.

Quoted 10 lines

Quoted 5 lines
Great.
it seems very useful.
and, I found no bug.
Reviewed-by KOSAKI Motohiro <[email protected]>
I was just about to ask whether we actually need the feature - I don't recall ever having needed it, nor do I recall seeing anyone else need it.
Why is it useful?

to be honest, I tought this is merely good debug feature. but crishtoph-san already explained it is more useful things.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>