linux-kernel - Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 27 Apr 2021 15:53:30 -0600
From:   Yu Zhao <yuzhao@...gle.com>
To:     "Huang, Ying" <ying.huang@...el.com>,
        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>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Michal Hocko <mhocko@...e.com>, wfg@...l.ustc.edu.cn
Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated()

On Sat, Apr 24, 2021 at 6:48 PM Huang, Ying <ying.huang@...el.com> wrote:
>
> Yu Zhao <yuzhao@...gle.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.