On Wed, Jul 13, 2016 at 11:24:13AM +0900, Minchan Kim wrote: > If we use sc->reclaim_idx for accounting pgstall, it can increase > the count on unpopulated zone, for example, movable zone(but > my system doesn't have movable zone) if allocation request were > GFP_HIGHUSER_MOVABLE. It doesn't make no sense. > I wanted to track the highest zone allowed by each allocation regardless of what the zone population state was. Otherwise, consider the following on a NUMA system 1. An allocation request arrives for GFP_HIGHUSER_MOVABLE that stalls 2. System has two nodes, node 0 with ZONE_NORMAL, node 1 with ZONE_HIGHMEM 3. If the allocating process is on node 0, the stall is accounted on ZONE_NORMAL 4. If the allocatinn process is on node 1, the stall is accounted on ZONE_HIGHMEM Multiple runs of the same workload on the same machine will see stall statistics on different zones and renders the stat useless. This is difficult to analyse because stalls accounted for on ZONE_NORMAL may or may not be zone-constrained allocations. The patch means that the vmstat accounting and tracepoint data is also out of sync. One thing I wanted to be able to do was 1. Observe that there are alloc stalls on DMA32 or some other low zone 2. Activate mm_vmscan_direct_reclaim_begin, filter on classzone_idx == DMA32 and identify the source of the lowmem allocations If your patch is applied, I cannot depend on the stall stats any more and the tracepoint is required to determine if there really any zone-contrained allocations. It can be *inferred* from the skip stats but only if such skips occurred and that is not guaranteed. -- Mel Gorman 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>