On Mon, Dec 12, 2011 at 09:59:20AM +0900, Minchan Kim wrote:

quoted

<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@kvack.org.  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@kvack.org"> email@kvack.org </a>