[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOUHufY_0WO5LJ13EL9-bQLvmNaaOpPFMVNUsRvYrefrLqS9aw@mail.gmail.com>
Date: Thu, 22 Apr 2021 14:57:22 -0600
From: Yu Zhao <yuzhao@...gle.com>
To: Xing Zhengjun <zhengjun.xing@...ux.intel.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linux-MM <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Huang Ying <ying.huang@...el.com>,
Michal Hocko <mhocko@...e.com>, wfg@...l.ustc.edu.cn,
Shakeel Butt <shakeelb@...gle.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Hugh Dickins <hughd@...gle.com>
Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated()
On Thu, Apr 22, 2021 at 2:38 PM Tim Chen <tim.c.chen@...ux.intel.com> wrote:
>
>
>
> On 4/22/21 1:30 PM, Yu Zhao wrote:
> >
> > HZ/10 is purely arbitrary but that's ok because we assume normally
> > nobody hits it. If you do often, we need to figure out why and how not
> > to hit it so often.
> >
>
> Perhaps Zhengjun can test the proposed fix in his test case to see if the timeout value
> makes any difference.
Shakeel has another test to stress page reclaim to a point that the
kernel can livelock for two hours because of a large number of
concurrent reclaimers stepping on each other. He might be able to
share that test with you in case you are interested.
Also it's Hugh who first noticed that migration can isolate many pages
and in turn block page reclaim. He might be able to help too, in case
you are interested in the interaction between migration and page
reclaim.
Thanks.
Powered by blists - more mailing lists