Re: [PATCH v3] migrate_pages: Avoid blocking for IO in MIGRATE_SYNC_LIGHT

[Hillf Danton <hdanton@sina.com>]

On 2 May 2023 14:20:54 -0700 Douglas Anderson <dianders@chromium.org>
> On Sun, Apr 30, 2023 at 1:53=E2=80=AFAM Hillf Danton <hdanton@sina.com> wrote:
> > On 28 Apr 2023 13:54:38 -0700 Douglas Anderson <dianders@chromium.org>
> > > The MIGRATE_SYNC_LIGHT mode is intended to block for things that will
> > > finish quickly but not for things that will take a long time. Exactly
> > > how long is too long is not well defined, but waits of tens of
> > > milliseconds is likely non-ideal.
> > >
> > > When putting a Chromebook under memory pressure (opening over 90 tabs
> > > on a 4GB machine) it was fairly easy to see delays waiting for some
> > > locks in the kcompactd code path of > 100 ms. While the laptop wasn't
> > > amazingly usable in this state, it was still limping along and this
> > > state isn't something artificial. Sometimes we simply end up with a
> > > lot of memory pressure.
> >
> > Given longer than 100ms stall, this can not be a correct fix if the
> > hardware fails to do more than ten IOs a second.
> >
> > OTOH given some pages reclaimed for compaction to make forward progress
> > before kswapd wakes kcompactd up, this can not be a fix without spotting
> > the cause of the stall.
> 
> Right that the system is in pretty bad shape when this happens and
> it's not very effective at doing IO or much of anything because it's
> under bad memory pressure.

Based on the info in another reply [1]

   | I put some more traces in and reproduced it again. I saw something
   | that looked like this:
   | 
   | 1. balance_pgdat() called wakeup_kcompactd() with order=10 and that
   | caused us to get all the way to the end and wakeup kcompactd (there
   | were previous calls to wakeup_kcompactd() that returned early).
   | 
   | 2. kcompactd started and completed kcompactd_do_work() without blocking.
   | 
   | 3. kcompactd called proactive_compact_node() and there blocked for
   | ~92ms in one case, ~120ms in another case, ~131ms in another case.

I see fragmentation given order=10 and proactive_compact_node(). Can you
specify the evidence of bad memory pressure?

[1] https://lore.kernel.org/lkml/CAD=FV=V8m-mpJsFntCciqtq7xnvhmnvPdTvxNuBGBT3-cDdabQ@mail.gmail.com/
> 
> I guess my first thought is that, when this happens then a process
> holding the lock gets preempted and doesn't get scheduled back in for
> a while. That _should_ be possible, right? In the case where I'm
> reproducing this then all the CPUs would be super busy madly trying to
> compress / decompress zram, so it doesn't surprise me that a process
> could get context switched out for a while.

Could switchout turn the below I/O upside down?
		/*
		 * In "light" mode, we can wait for transient locks (eg
		 * inserting a page into the page table), but it's not
		 * worth waiting for I/O.
		 */