Re: regression in /proc/self/numa_maps with huge pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 19 Oct 2011 13:10:07 -0700
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, 19 Oct 2011 12:35:30 -0700
> Stephen Hemminger <shemminger@xxxxxxxxxx> wrote:
> 
> > We are working on an application that uses a library that uses
> > both huge pages and parses numa_maps.  This application is no longer
> > able to identify the socket id correctly for huge pages because the
> > that 'huge' is no longer part of /proc/self/numa_maps.
> > 
> > Basically, application sets up huge page mmaps, then reads /proc/self/numa_maps
> > and skips all entries without the string " huge ".  Then it looks for address
> > and socket info.
> > 
> > Why was this information dropped?
> 
> Mistake?
> 
> > Looks like the desire to be generic
> > overstepped the desire to remain compatible.
> 
> Or it was a mistake.
> 
> This?
> 
> --- a/fs/proc/task_mmu.c~a
> +++ a/fs/proc/task_mmu.c
> @@ -1009,6 +1009,9 @@ static int show_numa_map(struct seq_file
>  		seq_printf(m, " stack");
>  	}
>  
> +	if (is_vm_hugetlb_page(vma))
> +		seq_printf(m, " huge");
> +
>  	walk_page_range(vma->vm_start, vma->vm_end, &walk);
>  
>  	if (!md->pages)
> 

That works, the application is happy.
Never would have found it except someone put the CPU in the wrong socket
on one dual CPU motherboard so everything is reported as socket 1!

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]