[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1222098955.8533.50.camel@nimitz>
Date: Mon, 22 Sep 2008 08:55:55 -0700
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: Mel Gorman <mel@....ul.ie>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 1/2] Report the pagesize backing a VMA in
/proc/pid/smaps
On Mon, 2008-09-22 at 02:38 +0100, Mel Gorman wrote:
> It is useful to verify that a hugepage-aware application is using the expected
> pagesizes in each of its memory regions. This patch reports the pagesize
> backing the VMA in /proc/pid/smaps. This should not break any sensible
> parser as the file format is multi-line and it should skip information it
> does not recognise.
Time to play devil's advocate. :)
To be fair, this doesn't return the MMU pagesize backing the VMA. It
returns pagesize that hugetlb reports *or* the kernel's base PAGE_SIZE.
The ppc64 case where we have a 64k PAGE_SIZE, but no hardware 64k
support means that we'll have a 4k MMU pagesize that we're pretending is
a 64k MMU page. That might confuse someone seeing 16x the number of TLB
misses they expect.
This also doesn't work if, in the future, we get multiple page sizes
mapped under one VMA. But, I guess that all only matters if you worry
about how the kernel is treating the pages vs. the MMU hardware.
-- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists