Message-Id: <20150807153547.04cf3a12ae095fcdd19da670@linux-foundation.org>
Date:	Fri, 7 Aug 2015 15:35:47 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	PINTU KUMAR <pintu.k@...sung.com>
Cc:	"'Michal Hocko'" <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, minchan@...nel.org, dave@...olabs.net,
	koct9i@...il.com, mgorman@...e.de, vbabka@...e.cz,
	js1304@...il.com, hannes@...xchg.org, alexander.h.duyck@...hat.com,
	sasha.levin@...cle.com, cl@...ux.com, fengguang.wu@...el.com,
	cpgs@...sung.com, pintu_agarwal@...oo.com, pintu.k@...look.com,
	vishnu.ps@...sung.com, rohit.kr@...sung.com
Subject: Re: [PATCH 1/1] mm: vmstat: introducing vm counter for slowpath

On Fri, 07 Aug 2015 18:16:47 +0530 PINTU KUMAR <pintu.k@...sung.com> wrote:

> > > This is useful to know the rate of allocation success within the
> > > slowpath.
> > 
> > What would be that information good for? Is a regular administrator expected
> to
> > consume this value or this is aimed more to kernel developers? If the later
> then I
> > think a trace point sounds like a better interface.
> > 
> This information is good for kernel developers.
> I found this information useful while debugging low memory situation and
> sluggishness behavior.
> I wanted to know how many times the first allocation is failing and how many
> times system entering slowpath.
> As I said, the existing counter does not give this information clearly. 
> The pageoutrun, allocstall is too confusing.
> Also, if kswapd and compaction is disabled, we have no other counter for
> slowpath (except allocstall).
> Another problem is that allocstall can also be incremented from hibernation
> during shrink_all_memory calling.
> Which may create more confusion.
> Thus I found this interface useful to understand low memory behavior.
> If device sluggishness is happening because of too many slowpath or due to some
> other problem.
> Then we can decide what will be the best memory configuration for my device to
> reduce the slowpath.
> 
> Regarding trace points, I am not sure if we can attach counter to it.
> Also trace may have more over-head and requires additional configs to be enabled
> to debug.
> Mostly these configs will not be enabled by default (at least in embedded, low
> memory device).
> I found the vmstat interface more easy and useful.

This does seem like a pretty basic and sensible thing to expose in
vmstat.  It probably makes more sense than some of the other things we
have in there.

Yes, it could be a tracepoint but practically speaking, a tracepoint
makes it developer-only.  You can ask a bug reporter or a customer
"what is /proc/vmstat:slowpath_entered" doing, but it's harder to ask
them to set up tracing.

And I don't think this will lock us into anything - vmstat is a big
dumping ground and I don't see a big problem with removing or changing
things later on.  IMO, debugfs rules apply here and vmstat would be in
debugfs, had debugfs existed at the time.


Two things:

- we appear to have forgotten to document /proc/vmstat

- How does one actually use slowpath_entered?  Obviously we'd like to
  know "what proportion of allocations entered the slowpath", so we
  calculate

	slowpath_entered/X

  how do we obtain "X"?  Is it by adding up all the pgalloc_*?  If
  so, perhaps we should really have slowpath_entered_dma,
  slowpath_entered_dma32, ...?
--
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