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" <vcap...@pengaru.com> > > To: "Hussam Al-Tayeb" <hussam.alta...@gmx.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 <g...@fb.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. > > > > > > [g...@fb.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-g...@fb.com > > > Signed-off-by: Roman Gushchin <g...@fb.com> > > > Reviewed-by: Andrew Morton <a...@linux-foundation.org> > > > Cc: Johannes Weiner <han...@cmpxchg.org> > > > Cc: Michal Hocko <mho...@kernel.org> > > > Cc: Tejun Heo <t...@kernel.org> > > > Cc: Rik van Riel <r...@surriel.com> > > > Cc: Konstantin Khlebnikov <koc...@gmail.com> > > > Cc: Matthew Wilcox <wi...@infradead.org> > > > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > > > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> > > > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.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
