On Tue 19-10-21 09:42:38, Vasily Averin wrote:

On 19.10.2021 08:33, Shakeel Butt wrote:

quoted

On Mon, Oct 18, 2021 at 11:52 AM Vasily Averin [off-list ref] wrote:

quoted

On 18.10.2021 18:07, Shakeel Butt wrote:

quoted

On Mon, Oct 18, 2021 at 5:27 AM Michal Hocko [off-list ref] wrote:

quoted

[restore the cc list]

On Mon 18-10-21 15:14:26, Vasily Averin wrote:

quoted

On 18.10.2021 14:53, Michal Hocko wrote:

quoted

On Mon 18-10-21 13:05:35, Vasily Averin wrote:

quoted

On 18.10.2021 12:04, Michal Hocko wrote:
Here we call try_charge_memcg() that return success and approve the allocation,
however then we hit into kmem limit and fail the allocation.

Just to make sure I understand this would be for the v1 kmem explicit
limit, correct?

yes, I mean this limit.

OK, thanks for the clarification. This is a known problem. Have a look
at I think we consider that one to 0158115f702b ("memcg, kmem: deprecate
kmem.limit_in_bytes"). We are reporting the deprecated and to-be removed
status since 2019 without any actual report sugested by the kernel
message. Maybe we should try and remove it and see whether that prompts
some pushback.

Yes, I think now should be the right time to take the next step for
deprecation of kmem limits:
https://lore.kernel.org/all/20201118175726.2453120-1-shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org/

Are you going to push it to stable kernels too?

Not really. Is there a reason I should? More exposure to catch breakage?

There is a problem: kmem limit can trigger fake global OOM.
To fix it in upstream you can remove kmem controller.

However how to handle this problem in stable and LTS kernels?

I do not see any bug reports coming in and I strongly suspect this is
because the functionality is simply not used wildly enough or in the
mode where it would matter (U != 0, K < U from our documentation).
If there are relevant usecases for this setup then we really want to
hear about those because we do not want to break userspace. Handling
that setup would far from trivial and the global oom killer is not the
only one of those.

My current patch resolves the problem too, and it can be backported.
However I afraid nobody will do it if teh patch will not be approved in upsteam.

I do not think your current approach is the right one. We do not really
want yet another flag to tell we are in a memcg OOM. We already have
one.

A proper way is to deal with the pagefault oom killer trigger but that
might be just too risky for stable kernels. 
-- 
Michal Hocko
SUSE Labs