| Message ID | 1559025859-72759-1-git-send-email-yang.shi@linux.alibaba.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v7,1/2] mm: vmscan: remove double slab pressure by inc'ing sc->nr_scanned | expand |
On Tue, 2019-05-28 at 14:44 +0800, Yang Shi wrote: > The commit 9092c71bb724 ("mm: use sc->priority for slab shrink > targets") > has broken up the relationship between sc->nr_scanned and slab > pressure. > The sc->nr_scanned can't double slab pressure anymore. So, it sounds > no > sense to still keep sc->nr_scanned inc'ed. Actually, it would > prevent > from adding pressure on slab shrink since excessive sc->nr_scanned > would > prevent from scan->priority raise. Hi Yang, I might be misunderstanding this, but did you mean "prevent from scan- priority decreasing"? I guess we are talking about balance_pgdat(), and in case kswapd_shrink_node() returns true (it means we have scanned more than we had to reclaim), raise_priority becomes false, and this does not let sc->priority to be decreased, which has the impact that less pages will be reclaimed the next round. Sorry for bugging here, I just wanted to see if I got this right.
On 6/10/19 2:36 PM, Oscar Salvador wrote: > On Tue, 2019-05-28 at 14:44 +0800, Yang Shi wrote: >> The commit 9092c71bb724 ("mm: use sc->priority for slab shrink >> targets") >> has broken up the relationship between sc->nr_scanned and slab >> pressure. >> The sc->nr_scanned can't double slab pressure anymore. So, it sounds >> no >> sense to still keep sc->nr_scanned inc'ed. Actually, it would >> prevent >> from adding pressure on slab shrink since excessive sc->nr_scanned >> would >> prevent from scan->priority raise. > Hi Yang, > > I might be misunderstanding this, but did you mean "prevent from scan- > priority decreasing"? > I guess we are talking about balance_pgdat(), and in case > kswapd_shrink_node() returns true (it means we have scanned more than > we had to reclaim), raise_priority becomes false, and this does not let > sc->priority to be decreased, which has the impact that less pages will > be reclaimed the next round. Yes, exactly. > > Sorry for bugging here, I just wanted to see if I got this right. > >
On 6/11/19 10:12 AM, Yang Shi wrote: > > > On 6/10/19 2:36 PM, Oscar Salvador wrote: >> On Tue, 2019-05-28 at 14:44 +0800, Yang Shi wrote: >>> The commit 9092c71bb724 ("mm: use sc->priority for slab shrink >>> targets") >>> has broken up the relationship between sc->nr_scanned and slab >>> pressure. >>> The sc->nr_scanned can't double slab pressure anymore. So, it sounds >>> no >>> sense to still keep sc->nr_scanned inc'ed. Actually, it would >>> prevent >>> from adding pressure on slab shrink since excessive sc->nr_scanned >>> would >>> prevent from scan->priority raise. >> Hi Yang, >> >> I might be misunderstanding this, but did you mean "prevent from scan- >> priority decreasing"? >> I guess we are talking about balance_pgdat(), and in case >> kswapd_shrink_node() returns true (it means we have scanned more than >> we had to reclaim), raise_priority becomes false, and this does not let >> sc->priority to be decreased, which has the impact that less pages will >> be reclaimed the next round. > > Yes, exactly. BTW, for the scan priority, the smaller number the higher priority. So, either "raise" or "decrease" sounds correct. "raise" means the real priority, "decrease" means the number itself. > >> >> Sorry for bugging here, I just wanted to see if I got this right. >> >> >
diff --git a/mm/vmscan.c b/mm/vmscan.c index 7acd0af..b65bc50 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1137,11 +1137,6 @@ static unsigned long shrink_page_list(struct list_head *page_list, if (!sc->may_unmap && page_mapped(page)) goto keep_locked; - /* Double the slab pressure for mapped and swapcache pages */ - if ((page_mapped(page) || PageSwapCache(page)) && - !(PageAnon(page) && !PageSwapBacked(page))) - sc->nr_scanned++; - may_enter_fs = (sc->gfp_mask & __GFP_FS) || (PageSwapCache(page) && (sc->gfp_mask & __GFP_IO));
The commit 9092c71bb724 ("mm: use sc->priority for slab shrink targets") has broken up the relationship between sc->nr_scanned and slab pressure. The sc->nr_scanned can't double slab pressure anymore. So, it sounds no sense to still keep sc->nr_scanned inc'ed. Actually, it would prevent from adding pressure on slab shrink since excessive sc->nr_scanned would prevent from scan->priority raise. The bonnie test doesn't show this would change the behavior of slab shrinkers. w/ w/o /sec %CP /sec %CP Sequential delete: 3960.6 94.6 3997.6 96.2 Random delete: 2518 63.8 2561.6 64.6 The slight increase of "/sec" without the patch would be caused by the slight increase of CPU usage. Cc: Josef Bacik <josef@toxicpanda.com> Cc: Michal Hocko <mhocko@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com> --- v4: Added Johannes's ack mm/vmscan.c | 5 ----- 1 file changed, 5 deletions(-)