linux-kernel - Re: [PATCH 7/8] mm/vmscan: Increase the timeout if page reclaim is not making progress

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]

Message-ID: <20211022081450.GH3959@techsingularity.net>
Date:   Fri, 22 Oct 2021 09:14:50 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     NeilBrown <neilb@...e.de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        "Darrick J . Wong" <djwong@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Michal Hocko <mhocko@...e.com>,
        Dave Chinner <david@...morbit.com>,
        Rik van Riel <riel@...riel.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Linux-MM <linux-mm@...ck.org>,
        Linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/8] mm/vmscan: Increase the timeout if page reclaim is
 not making progress

On Fri, Oct 22, 2021 at 12:07:43PM +1100, NeilBrown wrote:
> On Tue, 19 Oct 2021, Mel Gorman wrote:
> > Tracing of the stutterp workload showed the following delays
> > 
> >       1 usect_delayed=124000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=128000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=176000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=536000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=544000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=556000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=624000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=716000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       1 usect_delayed=772000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >       2 usect_delayed=512000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >      16 usect_delayed=120000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >      53 usect_delayed=116000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >     116 usect_delayed=112000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >    5907 usect_delayed=108000 reason=VMSCAN_THROTTLE_NOPROGRESS
> >   71741 usect_delayed=104000 reason=VMSCAN_THROTTLE_NOPROGRESS
> > 
> > All the throttling hit the full timeout and then there was wakeup delays
> > meaning that the wakeups are premature as no other reclaimer such as
> > kswapd has made progress. This patch increases the maximum timeout.
> 
> Would love to see the comparable tracing results for after the patch.
> 

They're in the leader. The trace figures in the changelog are the ones I
had at the time the patch was developed and I didn't keep them up to date
to reduce overall test time. At the last set of results, some throttling
was still hitting the full timeout;

  [....]
    843 usec_timeout=500000 usect_delayed=12000 reason=VMSCAN_THROTTLE_NOPROGRESS
   1299 usec_timeout=500000 usect_delayed=104000 reason=VMSCAN_THROTTLE_NOPROGRESS
   2839 usec_timeout=500000 usect_delayed=8000 reason=VMSCAN_THROTTLE_NOPROGRESS
  10111 usec_timeout=500000 usect_delayed=4000 reason=VMSCAN_THROTTLE_NOPROGRESS
  21492 usec_timeout=500000 usect_delayed=0 reason=VMSCAN_THROTTLE_NOPROGRESS
  36441 usec_timeout=500000 usect_delayed=500000 reason=VMSCAN_THROTTLE_NOPROGRESS


-- 
Mel Gorman
SUSE Labs