On Mon, Dec 12, 2011 at 09:59:20AM +0900, Minchan Kim wrote: > > <SNIP> > > @@ -1237,7 +1237,7 @@ static unsigned long isolate_pages_global(unsigned long nr, > > if (file) > > lru += LRU_FILE; > > return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, order, > > - mode, file); > > + mode, active, file); > > I guess you want to count exact scanning number of which lru list. > But It's impossible now since we do lumpy reclaim so that trace's > result is mixed by active/inactive list scanning. > And I don't like adding new argument for just trace although it's trivial. > FWIW, lumpy reclaim is why the trace point does not report the active or file information. Seeing active==1 does not imply that only active pages were isolated and mode is already there as Minchan points out. Similarly, seeing file==1 does not imply that only file-backed pages were isolated. Any processing script that depends on just this information would be misleading. If more information on how much each LRU was scanned is required, the mm_vmscan_lru_shrink_inactive tracepoint already reports the number of pages scanned, reclaimed and whether the pages isolated were anon, file or both so ordinarily I would suggest using just that. That said, I see that trace_shrink_flags() is currently misleading as it should be used sc->order instead of sc->reclaim_mode to determine if it was file, anon or a mix of both that was isolated. That should be fixed. If isolate_lru_pages really needs to export the file information, then it would be preferable to fix trace_shrink_flags() and use it to indicate if it was file, anon or a mix of both that was isolated. The information needed to trace this is not available in isolate_lru_pages so it would need to be passed down. Even with that, I would also like to see trace/postprocess/trace-vmscan-postprocess.pl updated to illustrate how this new information can be used to debug a problem or at least describe what sort of problem it can debug. > I think 'mode' is more proper rather than specific 'active'. > The 'mode' can achieve your goal without passing new argument "active". > True. > In addition to, current mmotm has various modes. > So sometime we can get more specific result rather than vauge 'active'. > Which also means that trace/postprocess/trace-vmscan-postprocess.pl is not using mm_vmscan_lru_isolate properly as it does not understand ISOLATE_CLEAN and ISOLATE_UNMAPPED. The impact for the script is that the scan count it reports will deviate from what /proc/vmstat reports which is irritating. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>