linux-kernel - Re: Excessive swapping under Linux 4.14.91 (no issues in 4.14.90).

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>] [day] [month] [year] [list]

Date:   Thu, 3 Jan 2019 12:59:24 -0800
From:   Vito Caputo <vcaputo@...garu.com>
To:     Hussam Al-Tayeb <hussam.altayeb@....com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Excessive swapping under Linux 4.14.91 (no issues in 4.14.90).

On Thu, Jan 03, 2019 at 09:33:09PM +0100, Hussam Al-Tayeb wrote:
> > Sent: Thursday, January 03, 2019 at 10:12 PM
> > From: "Vito Caputo" <vcaputo@...garu.com>
> > To: "Hussam Al-Tayeb" <hussam.altayeb@....com>
> > Subject: Re: Excessive swapping under Linux 4.14.91 (no issues in 4.14.90).
> >
> > 
> > The diff between 4.14.90 and 4.14.91 is rather small, appended below is
> > the entire shortlog.
> > 
> > There's only mm one commit:
> > 
> > > commit 36f93a2e7dce0a4f58b96a7ecb3af4e5897a60d4
> > > Author: Roman Gushchin <guro@...com>
> > > Date:   Fri Oct 26 15:03:27 2018 -0700
> > > 
> > >     mm: don't miss the last page because of round-off error
> > >     
> > >     commit 68600f623d69da428c6163275f97ca126e1a8ec5 upstream.
> > >     
> > >     I've noticed, that dying memory cgroups are often pinned in memory by a
> > >     single pagecache page.  Even under moderate memory pressure they sometimes
> > >     stayed in such state for a long time.  That looked strange.
> > >     
> > >     My investigation showed that the problem is caused by applying the LRU
> > >     pressure balancing math:
> > >     
> > >       scan = div64_u64(scan * fraction[lru], denominator),
> > >     
> > >     where
> > >     
> > >       denominator = fraction[anon] + fraction[file] + 1.
> > >     
> > >     Because fraction[lru] is always less than denominator, if the initial scan
> > >     size is 1, the result is always 0.
> > >     
> > >     This means the last page is not scanned and has
> > >     no chances to be reclaimed.
> > >     
> > >     Fix this by rounding up the result of the division.
> > >     
> > >     In practice this change significantly improves the speed of dying cgroups
> > >     reclaim.
> > >     
> > >     [guro@...com: prevent double calculation of DIV64_U64_ROUND_UP() arguments]
> > >       Link: http://lkml.kernel.org/r/20180829213311.GA13501@castle
> > >     Link: http://lkml.kernel.org/r/20180827162621.30187-3-guro@fb.com
> > >     Signed-off-by: Roman Gushchin <guro@...com>
> > >     Reviewed-by: Andrew Morton <akpm@...ux-foundation.org>
> > >     Cc: Johannes Weiner <hannes@...xchg.org>
> > >     Cc: Michal Hocko <mhocko@...nel.org>
> > >     Cc: Tejun Heo <tj@...nel.org>
> > >     Cc: Rik van Riel <riel@...riel.com>
> > >     Cc: Konstantin Khlebnikov <koct9i@...il.com>
> > >     Cc: Matthew Wilcox <willy@...radead.org>
> > >     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> > >     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> > >     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > 
> > If you're up for compiling a kernel, you could try reverting just
> > 36f93a2e from 4.14.91 and seeing if your problem goes away.
> > 
> > Regards,
> > Vito Caputo
> 
> I will do that. Thank you.

I just realized I didn't include lkml in replying to you, so I'm adding
them now for posterity.  Please include the list in any further
discussion.

Regards,
Vito Caputo