Re: [PATCH 4/4] mm: delay page_remove_rmap() until after the TLB has been flushed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 9 Nov 2022, Johannes Weiner wrote:

> All 4 patches look good to me from an MM and cgroup point of view.

Yes, same here from me.

I was running my load on them (applied to 6.1-rc4) overnight, intending
to go for 20 hours.  It stopped just a few minutes short, for some fork
ENOMEM reason I've never (or not in a long time) seen before; but I don't
often run for that long, and I think if there were some new error in the
page freeing in the patches, it would have shown up very much quicker.

So I'd guess the failure was 99.9% likely unrelated, and please go ahead
with getting the patches into mm-unstable.

> 
> And with the pte still locked over rmap, we can continue with the
> removal of the cgroup-specific locking and rely on native MM
> synchronization, which is great as well.

Yes, please go ahead with that Johannes: and many thanks for coming to
the rescue with your input on the other thread.  But you'll find that
the mm/rmap.c source in mm-unstable is a bit different from 6.1-rc,
so your outlined patch will need some changes - or pass it over to
me for that if you prefer.  (And I do have one more patch to that,
hope to post later today: just rearranging the order of tests as
Linus preferred.)

Hugh




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux