[lkml]   [2011]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH V2] vmscan/trace: Add 'active' and 'file' info to trace_mm_vmscan_lru_isolate.
    Hi Mel,
    On 12/12/2011 07:27 PM, Mel Gorman wrote:
    > 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.
    OK, thanks for the info.
    > 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.
    So how can I tell the isolation list status when we do shrink_active_list?
    > 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.
    sure, I will see how to work it out.
    > 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/ 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.
    Sorry, I don't ever know the existence of this script. And I will update
    this script in the next try.
    >> 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/
    > 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.
    Let me see whether I can fix it or not.


     \ /
      Last update: 2011-12-13 15:43    [W:0.024 / U:219.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site