Comment # 45 on bug 1159882 from Michal Hocko

(In reply to Andrei Borzenkov from comment #29)
> (In reply to Miroslav Bene�� from comment #26)
> > It is not surprising to see it strikes 15.2 too. The original bug was
> > reported against 5.3 kernel, which is in 15.2. It got somehow fixed in 5.6
> > at the latest. We may try to find the fixes but they may be too intrusive to
> > backport.
> > 
> 
> The commit 2c012a4ad1a2cd3fb5a0f9307b9d219f84eda1fa mentioned in comment #14
> was effectively removed in commit b91ac374346ba206cfd568bb0ab830af6b205cfd
> which went into 5.5. I actually observed quite similar symptoms in Ubuntu
> 18.04 as soon as it bumped HWE kernel to 5.3 and had to install 5.5 (5.4 had
> the same issue).
> 
> I do not know if b91ac374346ba206cfd568bb0ab830af6b205cfd alone can be back
> ported but may be 2c012a4ad1a2cd3fb5a0f9307b9d219f84eda1fa could be reverted
> as this is what happened in upstream anyway.

I have read through this bugzilla again and noticed that I have missed this
comment previously. So reverting 2c012a4ad1a2c is not really straightforward
exactly because of b91ac374346 which openSUSE-15.2 kernel has as well. And
looking closer it can contribute to the problem itself. Mostly because it
of 
+               /*
+                * When refaults are being observed, it means a new
+                * workingset is being established. Deactivate to get
+                * rid of any stale active pages quickly.
+                */
+               refaults = lruvec_page_state(target_lruvec,
+                                            WORKINGSET_ACTIVATE);
+               if (refaults != target_lruvec->refaults ||
+                   inactive_is_low(target_lruvec, LRU_INACTIVE_FILE))
+                       sc->may_deactivate |= DEACTIVATE_FILE;
+               else
+                       sc->may_deactivate &= ~DEACTIVATE_FILE;
[...]
+       if (file >> sc->priority && !(sc->may_deactivate & DEACTIVATE_FILE))
+               sc->cache_trim_mode = 1;
+       else
+               sc->cache_trim_mode = 0;

note how refaults != target_lruvec->refaults can easily move us to SCAN_FRACT
even if there is a lot of page cache after a single activation. 2c012a4ad1a2c
was less agresive in that regards because it only forced active -> inactive
rebalance on an activation.

I might be misreading this, the logic is quite convoluted but it should be
pretty straightforward to drop this patch and have you retest it.

Ccing Mel as well.