Messages in this thread |  | | | Date | Mon, 12 Dec 2011 11:27:38 +0000 | | From | Mel Gorman <> | | Subject | Re: [PATCH V2] vmscan/trace: Add 'active' and 'file' info to trace_mm_vmscan_lru_isolate. |
| |
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |