lkml.org 
[lkml]   [2015]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCHSET 0/6] perf kmem: Implement page allocation analysis (v1)

* Namhyung Kim <namhyung@kernel.org> wrote:

> Hi Ingo,
>
> On Thu, Mar 12, 2015 at 04:54:22PM +0100, Ingo Molnar wrote:
> >
> > * Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > > > I.e. something like this (mockup) output:
> > > >
> > > > SUMMARY (page allocator)
> > > > ========================
> > > >
> > > > Pages allocated+freed: 12,593 [ 51,630,080 bytes ]
> > > >
> > > > Pages allocated-only: 2,342 [ 1,235,010 bytes ]
> > > > Pages freed-only: 67 [ 135,311 bytes ]
> > > >
> > > > Page allocation failures : 0
> > >
> > > Looks a lot better!
> > >
> > > One thing I need to tell you is that the numbers are not pages but
> > > requests.
> >
> > Yes, but in the MM code we tend to call larger order allocations
> > 'pages' as well: higher order pages, such as a 2MB hugepage, or a 8K
> > order-1 page. So at least in MM-speak it should be OK to call them
> > 'pages'.
> >
> > But your call!
>
> How about this?
>
> SUMMARY (page allocator)
> ========================
> Total allocation requests : 9,015 [ 37,200 Kbytes ] (A)
> Total free requests : 8,093 [ 33,176 Kbytes ] (B)
>
> Total alloc+freed requests : 7,985 [ 32,732 Kbytes ] (C)
> Total alloc-only requests : 1,030 [ 4,468 Kbytes ] (D)
> Total free-only requests : 108 [ 444 Kbytes ] (E)
>
> Total allocation failure : 0 [ 0 Kbytes ]

s/failure/failures
s/Kbytes/KB

I'd leave a bit more space for the numbers, for up into billions of
requests and terabytes of data. Other than that, sounds good to me!

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-03-13 14:01    [W:0.047 / U:4.524 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site