Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210416023536.168632-1-zhengjun.xing@linux.intel.com>
 <7b7a1c09-3d16-e199-15d2-ccea906d4a66@linux.intel.com> <YIGuvh70JbE1Cx4U@google.com>
 <7a0fecab-f9e1-ad39-d55e-01e574a35484@linux.intel.com> <YIMsykToLKUVMWbZ@google.com>
 <87fszfxk89.fsf@yhuang6-desk1.ccr.corp.intel.com>
In-Reply-To: <87fszfxk89.fsf@yhuang6-desk1.ccr.corp.intel.com>
From:   Yu Zhao <yuzhao@google.com>
Date:   Tue, 27 Apr 2021 15:53:30 -0600
Message-ID: <CAOUHufYa79naFrai3T5Tkd+TW4Lvk3PUzeeg68mhZ_1M7Pe2jQ@mail.gmail.com>
Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated()
To:     "Huang, Ying" <ying.huang@intel.com>,
        Xing Zhengjun <zhengjun.xing@linux.intel.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Shakeel Butt <shakeelb@google.com>,
        Michal Hocko <mhocko@suse.com>, wfg@mail.ustc.edu.cn
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Apr 24, 2021 at 6:48 PM Huang, Ying <ying.huang@intel.com> wrote:
>
> Yu Zhao <yuzhao@google.com> writes:
> [snip]
>
> > @@ -2966,13 +2938,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
> >                       /* need some check for avoid more shrink_zone() */
> >               }
> >
> > -             /* See comment about same check for global reclaim above */
> > -             if (zone->zone_pgdat == last_pgdat)
> > -                     continue;
> > -             last_pgdat = zone->zone_pgdat;
> >               shrink_node(zone->zone_pgdat, sc);
> >       }
> >
> > +     if (last_pgdat)
> > +             atomic_dec(&last_pgdat->nr_reclaimers);
> > +     else if (should_retry) {
> > +             /* wait a bit for the reclaimer. */
> > +             if (!schedule_timeout_killable(HZ / 10))
>
> Once we reached here, even accidentally, the caller needs to sleep at
> least 100ms.  How about use a semaphore for pgdat->nr_reclaimers?  Then
> the sleeper can be waken up when the resource is considered enough.

Yeah, that sounds good to me. I guess we will have to wait and see the
test result from Zhengjun.

Thanks.