Re: [PATCH] memcg: Don't call schedule_work when no spinning is allowed

[Michal Hocko]

On Tue 01-09-26 16:59:46, Johannes Weiner wrote:
> On Tue, Sep 01, 2026 at 05:42:30PM +0200, Michal Hocko wrote:
> > On Tue 01-09-26 10:25:52, Johannes Weiner wrote:
> > > On Mon, Aug 31, 2026 at 06:04:57PM -0700, David Stevens wrote:
> > [...]
> > > > There would be no guarantee that memcg reclaim would ever be
> > > > triggered, which also would also stop MEMCG_HIGH events from being
> > > > generated. Overall that seems a more serious than just dropping
> > > > userspace notifications like is done for MEMCG_MAX.
> > > 
> > > I'm leaning that way too. It's an indefinite error, and it's a freely
> > > programmable surface.
> > 
> > I am really curious about the indefinite error side of things. It has
> > been my understanding that these NMI safe charges are a) rare and b)
> > there is userspace running so eventually any discrepancies would
> > resolve so the excess is temporary.
> 
> So I think the question is what limits the error in both space and
> time. When you say it's rare and userspace fixes it, it basically
> means the answer is: luck of the common case.

Right. I was asking because so far we are trying these allocations as
more or less trusted (we do allow them to breach the high limit without
any pushback). If there are known scenarios where this could run away
then we might need to re-evaluate that. Async reclaim might be just too
late in those cases.

Anway...

> But that doesn't help the worst case that can be triggered.
> 
> Like I said, if we need to have code to handle that !allow_spinning
> case anyway, I'd rather just have a few lines of working code than a
> (lengthy) comment explaining the luck of the common case.

Fair enough. A jump through irq work is not that bad from the complexity
POV. So you've convinced me

Acked-by: Michal Hocko <mhocko@xxxxxxxx>

Thanks!
-- 
Michal Hocko
SUSE Labs