Re: [PATCH 1/1] mm: vmstat: introducing vm counter for slowpath

[Andrew Morton]

On Fri, 07 Aug 2015 18:16:47 +0530 PINTU KUMAR <pintu.k@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/