On Sat, Jun 09, 2012 at 12:03:43PM +0300, Mikolaj Golub wrote: > > On Sat, 9 Jun 2012 11:38:22 +0300 Konstantin Belousov wrote: > > KB> On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote: > >> > >> On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote: > >> > >> IV> On 1 June 2012 14:35, Wojciech Puchar > <woj...@wojtek.tensor.gdynia.pl> wrote: > >> >>> http://people.freebsd.org/~ivoras/stuff/spsurvey.py > >> > >> ... > >> > >> IV> If anyone posts more data, I'll analyse it. I'm more worried about > the > >> IV> granularity of procstat, where it marks the entire region if a single > >> IV> superpage exists in it - it means any such analysis is only > >> IV> approximate. > >> > >> Here is a patch (for kernel and procstat) that allows to see amount of > pages > >> mapped to superpages. > >> > >> http://people.freebsd.org/~trociny/procstat-superpages.cnt.1.patch > >> > >> Not sure it is useful enough to be committed. > > KB> Superpage aggregates mappings for several normal-sized pages. > KB> As a consequence, when you iterate over small pages in > KB> sysctl_kern_proc_vmmap(), you account each superpage as many time as > KB> much constituent small pages it contains. > > This is exactly what my intention was to count: how much memory are handled by > superpages (using normal-sized page as a measurement unit), not amount of > superpages. And I think this is what Ivan wanted to know. Do you think it is > better to return number of superpages? > Well, if I see a report informing me that some 2M region contains 512 super pages, how should I interpret it ? For me, it is only one superpage (mapping) that can be created in one 2M region.
pgpjIsQYdxpkt.pgp
Description: PGP signature
