[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06da01d261aa$5e7b01e0$1b7105a0$@alibaba-inc.com>
Date: Thu, 29 Dec 2016 16:05:49 +0800
From: "Hillf Danton" <hillf.zj@...baba-inc.com>
To: "'Michal Hocko'" <mhocko@...nel.org>, <linux-mm@...ck.org>
Cc: "'Andrew Morton'" <akpm@...ux-foundation.org>,
"'Mel Gorman'" <mgorman@...e.de>,
"'Johannes Weiner'" <hannes@...xchg.org>,
"'Vlastimil Babka'" <vbabka@...e.cz>,
"'Rik van Riel'" <riel@...hat.com>,
"'LKML'" <linux-kernel@...r.kernel.org>,
"'Michal Hocko'" <mhocko@...e.com>
Subject: Re: [PATCH 6/7] mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint
On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote:
> From: Michal Hocko <mhocko@...e.com>
>
> mm_vmscan_lru_shrink_inactive will currently report the number of
> scanned and reclaimed pages. This doesn't give us an idea how the
> reclaim went except for the overall effectiveness though. Export
> and show other counters which will tell us why we couldn't reclaim
> some pages.
> - nr_dirty, nr_writeback, nr_congested and nr_immediate tells
> us how many pages are blocked due to IO
> - nr_activate tells us how many pages were moved to the active
> list
> - nr_ref_keep reports how many pages are kept on the LRU due
> to references (mostly for the file pages which are about to
> go for another round through the inactive list)
> - nr_unmap_fail - how many pages failed to unmap
>
> All these are rather low level so they might change in future but the
> tracepoint is already implementation specific so no tools should be
> depending on its stability.
>
> Signed-off-by: Michal Hocko <mhocko@...e.com>
> ---
Acked-by: Hillf Danton <hillf.zj@...baba-inc.com>
Powered by blists - more mailing lists