Message-ID: <YhNsaHLLfvFoxnNu@alley>
Date:   Mon, 21 Feb 2022 11:41:44 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
        hannes@...xchg.org, peterz@...radead.org, guro@...com,
        shakeelb@...gle.com, minchan@...nel.org, timmurray@...gle.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com
Subject: Re: [PATCH 1/1] mm: count time in drain_all_pages during direct
 reclaim as memory pressure

On Mon 2022-02-21 09:55:12, Michal Hocko wrote:
> On Sat 19-02-22 09:49:40, Suren Baghdasaryan wrote:
> > When page allocation in direct reclaim path fails, the system will
> > make one attempt to shrink per-cpu page lists and free pages from
> > high alloc reserves. Draining per-cpu pages into buddy allocator can
> > be a very slow operation because it's done using workqueues and the
> > task in direct reclaim waits for all of them to finish before
> > proceeding. Currently this time is not accounted as psi memory stall.
> > 
> > While testing mobile devices under extreme memory pressure, when
> > allocations are failing during direct reclaim, we notices that psi
> > events which would be expected in such conditions were not triggered.
> > After profiling these cases it was determined that the reason for
> > missing psi events was that a big chunk of time spent in direct
> > reclaim is not accounted as memory stall, therefore psi would not
> > reach the levels at which an event is generated. Further investigation
> > revealed that the bulk of that unaccounted time was spent inside
> > drain_all_pages call.
> 
> It would be cool to have some numbers here.
> 
> > Annotate drain_all_pages and unreserve_highatomic_pageblock during
> > page allocation failure in the direct reclaim path so that delays
> > caused by these calls are accounted as memory stall.
> 
> If the draining is too slow and dependent on the current CPU/WQ
> contention then we should address that. The original intention was that
> having a dedicated WQ with WQ_MEM_RECLAIM would help to isolate the
> operation from the rest of WQ activity. Maybe we need to fine tune
> mm_percpu_wq. If that doesn't help then we should revise the WQ model
> and use something else. Memory reclaim shouldn't really get stuck behind
> other unrelated work.

WQ_MEM_RECLAIM causes that one special worker (rescuer) is created for
the workqueue. It is used _only_ when new workers could not be created
for some, typically when there is non enough memory. It is just
a fallback, last resort. It does _not_ speedup processing.

Otherwise, "mm_percpu_wq" is a normal CPU-bound wq. It uses the shared
per-CPU worker pools. They serialize all work items on a single
worker. Another worker is used only when a work goes asleep and waits
for something.

It means that "drain" work is blocked by other work items that are
using the same worker pool and were queued earlier.


You might try to allocate "mm_percpu_wq" with WQ_HIGHPRI flag. It will
use another shared per-CPU worker pools where the workers have nice
-20. The "drain" work still might be blocked by another work items
using the same pool. But it should be faster because the workers
have higher priority.


Dedicated kthreads might be needed when the "draining" should not be
blocked by anything. If you go this way then I suggest to use
the kthread_worker API, see "linux/kthread.h". It is very similar
to the workqueues API but it always creates new kthreads.

Just note that kthread_worker API does not maintain per-CPU workers
on its own. If you need per-CPU workers than you need to
use kthread_create_worker_on_cpu() for_each_online_cpu().
And you would need cpu hotplug callbacks to create/destroy
ktheads. For example, see start_power_clamp_worker().

HTH,
Petr

Powered by blists - more mailing lists