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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 F30C5C4724C for ; Mon, 4 May 2020 16:06:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CDAC9206A4 for ; Mon, 4 May 2020 16:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588608378; bh=j9K/Nz2f64Gu6Trw3AzI9carqSeCZ7T73MNsRkGwxVA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KCdGuh9jP/8v8OuR1QKG1AYNfe1WrrlPjS5xZ9AANX/eSGgssxMxC+TLn53292R6F 01BIo8Md0TaPdKxz7YwKqH3VKU0dFHm4WjCbVMXlhQGnVNmpQzXyOdIly+0G1TlFSQ 94kaHMGLQhI7sFD8NRtM/2sj/NoDf57FPPbKrNns= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729499AbgEDQGS (ORCPT ); Mon, 4 May 2020 12:06:18 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:34631 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729141AbgEDQGR (ORCPT ); Mon, 4 May 2020 12:06:17 -0400 Received: by mail-wr1-f66.google.com with SMTP id y3so2589956wrt.1; Mon, 04 May 2020 09:06:15 -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=gz77ioJv/9dXqW2LTks1m6BbwjIcuICrqOvb8PaySYQ=; b=iQKwJjj3+0ie9fpeFWGs8T1C+Lq8Qxc4ct/wLyo6VI4DvFxe833gQhPHKslE+mGtnl +f/GWr4qhw25/FGvcvn4nPhjgMgM6nre/fF6Yjh9jmDrACDD5l70GfrJKXAuxzWpXK2c yT9cBtr9qmk8cNYinWqAfEltshBhQ87Y9D1E/GflkPIVjuNL//K27ju4cnsFxAf+xMaW sA0xVZU7u6gc0udjEMxYB5UJP6+3qerbSCJ7/OeD4rnmPckvugPy/nszlHbHSbeRYwdy pP9cV2pkZ+z/VDOmj5n7pcV0fi7v4RyVwgUvK0tCrHpJlyYDPpZxnAtSyvgKFh4b1QAT vS+Q== X-Gm-Message-State: AGi0Puadn+6ehpSEE1xHajTkV3/3gEmeI9OIDxkyTgqFIAo39LMFHESE DOHoq9JyJ2Qq6nuDrc+rimU= X-Google-Smtp-Source: APiQypL3n2ecP7nnkYr0BLQZTWMzDfU3njXWsN19/uQWkLzxn3+828cKXcT1957AXYHlfWLL9ElbXw== X-Received: by 2002:adf:f091:: with SMTP id n17mr30070wro.200.1588608375283; Mon, 04 May 2020 09:06:15 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id s8sm16137860wrt.69.2020.05.04.09.06.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 09:06:14 -0700 (PDT) Date: Mon, 4 May 2020 18:06:13 +0200 From: Michal Hocko To: Shakeel Butt Cc: 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: <20200504160613.GU22838@dhcp22.suse.cz> References: <20200430182712.237526-1-shakeelb@google.com> <20200504065600.GA22838@dhcp22.suse.cz> <20200504141136.GR22838@dhcp22.suse.cz> <20200504150052.GT22838@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 04-05-20 08:35:57, Shakeel Butt wrote: > On Mon, May 4, 2020 at 8:00 AM Michal Hocko wrote: > > > > On Mon 04-05-20 07:53:01, Shakeel Butt wrote: [...] > > > I am trying to see if "no eligible task" is really an issue and should > > > be warned for the "other use cases". The only real use-case I can > > > think of are resource managers adjusting the limit dynamically. I > > > don't see "no eligible task" a concerning reason for such use-case. > > > > It is very much a concerning reason to notify about like any other OOM > > situation due to hard limit breach. In this case it is worse in some > > sense because the limit cannot be trimmed down because there is no > > directly reclaimable memory at all. Such an oom situation is > > effectivelly conserved. > > -- > > Let me make a more precise statement and tell me if you agree. The "no > eligible task" is concerning for the charging path but not for the > writer of memory.max. The writer can read the usage and > cgroup.[procs|events] to figure out the situation if needed. I really hate to repeat myself but this is no different from a regular oom situation. Admin sets the hard limit and the kernel tries to act upon that. You cannot make any assumption about what admin wanted or didn't want to see. We simply trigger the oom killer on memory.max and this is a documented behavior. No eligible task or no task at all is a simply a corner case when the kernel cannot act and mentions that along with the oom report so that whoever consumes that information can debug or act on that fact. Silencing the oom report is simply removing a potentially useful aid to debug further a potential problem. But let me repeat this is not reallly any different from a regular oom situation when the oom killer is able to act. -- Michal Hocko SUSE Labs