Hi, > -----Original Message----- > From: Michal Hocko [mailto:mhocko@xxxxxxxxxx] > Sent: Friday, August 07, 2015 1:14 PM > To: Pintu Kumar > Cc: akpm@xxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > mm@xxxxxxxxx; minchan@xxxxxxxxxx; dave@xxxxxxxxxxxx; koct9i@xxxxxxxxx; > mgorman@xxxxxxx; vbabka@xxxxxxx; js1304@xxxxxxxxx; > hannes@xxxxxxxxxxx; alexander.h.duyck@xxxxxxxxxx; > sasha.levin@xxxxxxxxxx; cl@xxxxxxxxx; fengguang.wu@xxxxxxxxx; > cpgs@xxxxxxxxxxx; pintu_agarwal@xxxxxxxxx; pintu.k@xxxxxxxxxxx; > vishnu.ps@xxxxxxxxxxx; rohit.kr@xxxxxxxxxxx > Subject: Re: [PATCH 1/1] mm: vmstat: introducing vm counter for slowpath > > On Fri 07-08-15 12:38:54, Pintu Kumar wrote: > > This patch add new counter slowpath_entered in /proc/vmstat to track > > how many times the system entered into slowpath after first allocation > > attempt is failed. > > This is too lowlevel to be exported in the regular user visible interface IMO. > I think its ok because I think this interface is for lowlevel debugging itself. > > 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. Comments and suggestions are welcome. > > This patch is tested on ARM with 512MB RAM. > > A sample output is shown below after successful boot-up: > > shell> cat /proc/vmstat > > nr_free_pages 4712 > > pgalloc_normal 1319432 > > pgalloc_movable 0 > > pageoutrun 379 > > allocstall 0 > > slowpath_entered 585 > > compact_stall 0 > > compact_fail 0 > > compact_success 0 > > > > >From the above output we can see that the system entered > > slowpath 585 times. > > But the existing counter kswapd(pageoutrun), > > direct_reclaim(allocstall), > > direct_compact(compact_stall) does not tell this value. > > >From the above value, it clearly indicates that the system have > > entered slowpath 585 times. Out of which 379 times allocation passed > > through kswapd, without performing direct reclaim/compaction. > > That means the remaining 206 times the allocation would have succeeded > > using the alloc_pages_high_priority. > > > > Signed-off-by: Pintu Kumar <pintu.k@xxxxxxxxxxx> > -- > Michal Hocko > SUSE Labs -- 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>