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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>