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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73DFBC47257 for ; Mon, 4 May 2020 07:36:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B6BF20735 for ; Mon, 4 May 2020 07:36:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B6BF20735 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C5F508E0005; Mon, 4 May 2020 03:35:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0F0B8E0001; Mon, 4 May 2020 03:35:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B24D98E0005; Mon, 4 May 2020 03:35:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id 97C658E0001 for ; Mon, 4 May 2020 03:35:59 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 537EC12781 for ; Mon, 4 May 2020 07:35:59 +0000 (UTC) X-FDA: 76778227638.11.store37_6e752880c692a X-HE-Tag: store37_6e752880c692a X-Filterd-Recvd-Size: 4754 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 07:35:58 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id x25so7276501wmc.0 for ; Mon, 04 May 2020 00:35:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4M+FRCJ74peE16t8SYWvqws7mT6RU/FjWmJ/yEmHyz4=; b=uW9jms3DC8L+f5ij6fEe6LDDCMuh8aDTheoSfOXQEyVRvUKhdM0PqXVwpd1cYebjwt J8PPsFG82O2/OQuaZ6PEHpY4Fw2smqQz5WI+mcg7HQCc0wT85P16vay2TBDbC9aKKPx5 P0xbFDL5OoADA7BC63BVdIzpTq6CWeTNKO2dx0bpOeXd5qTEKwqQGGwMpJySgcxJXixR qOUCSUEFd/w7HlwOCAMddhzESx9FB2gKaBMwDVLbawms9KT2scEGoLYc6yUZGxVkpb1P Do6b/MOz6wfG5/xoHbs/YvQVd5d6ngDzHGUL7dFTjA4WIwLkcsu1XjRP/Ku3+vrD2l6f HIsA== X-Gm-Message-State: AGi0Pua61z3GG6kmZlz+QyRkhuicYprS+sI3s18XpAHLeeYCs/Wj6qz9 qVHkx79z5n+ZT7hz7yVj2yE= X-Google-Smtp-Source: APiQypKL4l5XzT5d8T4EDUnSiLIA6SEXjEYTfcdL4oM5Poxa+fvYuw8On5zLYw4uwlEgUzCW89McQg== X-Received: by 2002:a1c:b445:: with SMTP id d66mr13680620wmf.187.1588577757859; Mon, 04 May 2020 00:35:57 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id w6sm18583454wrm.86.2020.05.04.00.35.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 00:35:57 -0700 (PDT) Date: Mon, 4 May 2020 09:35:49 +0200 From: Michal Hocko To: Yafang Shao Cc: Shakeel Butt , Johannes Weiner , Roman Gushchin , Greg Thelen , Andrew Morton , Linux MM , Cgroups , LKML Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max Message-ID: <20200504073549.GE22838@dhcp22.suse.cz> References: <20200430182712.237526-1-shakeelb@google.com> <20200504070301.GC22838@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 04-05-20 15:26:52, Yafang Shao wrote: > On Mon, May 4, 2020 at 3:03 PM Michal Hocko wrote: > > > > On Fri 01-05-20 09:39:24, Yafang Shao wrote: > > > On Fri, May 1, 2020 at 2:27 AM Shakeel Butt wrote: > > > > > > > > Lowering memory.max can trigger an oom-kill if the reclaim does not > > > > succeed. However if oom-killer does not find a process for killing, it > > > > dumps a lot of warnings. > > > > > > > > > > I have been confused by this behavior for several months and I think > > > it will confuse more memcg users. > > > > Could you be more specific what has caused the confusion? > > > > No task is different from no eligible task. > No eligible task means there are some candidates but no one is eligible. > Whille no task means there is no candidate. I really fail to see a difference. It is clear the one is subset of the other but in practical life tasks might come and go at any time and if you try to reduce the hard limit and there are no tasks that could be reclaimed then I believe we should complain whether it is only oom disabled tasks or no tasks at all. It is certainly unexpected situation in some cases because there are resources which are bound to the memcg without any task we can act on. > > > We should keep the memcg oom behavior consistent with system oom - no > > > oom kill if no process. > > > > This is not the global mmemcg behavior. We do complain loud on no > > eligible tasks and actually panic the system. Memcg cannot simply > > do the same by default for obvious reasons. > > > > As explianed above, no eligible task is different from no task. > If there are some candidates but no one is eligible, the system will panic. > While if there's no task, it is definitely no OOM, because that's an > improssible thing for the system. This is very much possible situation when all eligible tasks have been already killed but they didn't really help to resolve the oom situation - e.g. in kernel memory leak or unbounded shmem consumption etc... -- Michal Hocko SUSE Labs