From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7022C433EF for ; Tue, 19 Oct 2021 08:47:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32A4961212 for ; Tue, 19 Oct 2021 08:47:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 32A4961212 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7D19B6B006C; Tue, 19 Oct 2021 04:47:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 781436B0071; Tue, 19 Oct 2021 04:47:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67052900002; Tue, 19 Oct 2021 04:47:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 56AF86B006C for ; Tue, 19 Oct 2021 04:47:13 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 11BBC181AF5C6 for ; Tue, 19 Oct 2021 08:47:13 +0000 (UTC) X-FDA: 78712557546.17.06051FB Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf29.hostedemail.com (Postfix) with ESMTP id 697909000247 for ; Tue, 19 Oct 2021 08:47:10 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 2D7F51FC9E; Tue, 19 Oct 2021 08:47:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1634633231; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0QHVkjPX9VWQRCDOqIEsYscNDDX26IKKHuDWyHZH10w=; b=obAil+Lvy/jiFKcRq+daqcHuy3BlO8iF3QBGc7EhSR8cyxH3Al4LqUe4xHFm073qBhTry1 nUBXAVFNa1/pxddYSY/AxT1ZnUX9i+lzvHm1IYcMGNka7Y+t5RUid2t95S0HGVjKREu3BF dBkp2OQGxxF2IifpgqYPxxS2OyJ64iw= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id AC166A3B8D; Tue, 19 Oct 2021 08:47:10 +0000 (UTC) Date: Tue, 19 Oct 2021 10:47:09 +0200 From: Michal Hocko To: Vasily Averin Cc: Shakeel Butt , Johannes Weiner , Vladimir Davydov , Andrew Morton , Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , Mel Gorman , Cgroups , Linux MM , LKML , kernel@openvz.org Subject: Re: [PATCH memcg 0/1] false global OOM triggered by memcg-limited task Message-ID: References: <9d10df01-0127-fb40-81c3-cc53c9733c3e@virtuozzo.com> <6b751abe-aa52-d1d8-2631-ec471975cc3a@virtuozzo.com> <27dc0c49-a0d6-875b-49c6-0ef5c0cc3ac8@virtuozzo.com> <153f7aa6-39ef-f064-8745-a9489e088239@virtuozzo.com> <25120323-d222-cc5e-fe08-6471bce13bd6@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25120323-d222-cc5e-fe08-6471bce13bd6@virtuozzo.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 697909000247 X-Stat-Signature: wx6e8y5gia885w7jf4kum1urssmonku4 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=obAil+Lv; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1634633230-327731 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 19-10-21 09:42:38, Vasily Averin wrote: > On 19.10.2021 08:33, Shakeel Butt wrote: > > On Mon, Oct 18, 2021 at 11:52 AM Vasily Averin wrote: > >> > >> On 18.10.2021 18:07, Shakeel Butt wrote: > >>> On Mon, Oct 18, 2021 at 5:27 AM Michal Hocko wrote: > >>>> > >>>> [restore the cc list] > >>>> > >>>> On Mon 18-10-21 15:14:26, Vasily Averin wrote: > >>>>> On 18.10.2021 14:53, Michal Hocko wrote: > >>>>>> On Mon 18-10-21 13:05:35, Vasily Averin wrote: > >>>>>>> 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@google.com/ > >> > >> 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