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,URIBL_BLOCKED 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 8D571C47254 for ; Tue, 5 May 2020 15:49:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5424A206B9 for ; Tue, 5 May 2020 15:49:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5424A206B9 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 E08268E0008; Tue, 5 May 2020 11:49:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D90E98E0003; Tue, 5 May 2020 11:49:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C583A8E0008; Tue, 5 May 2020 11:49:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id A90098E0003 for ; Tue, 5 May 2020 11:49:47 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6B06F824CA03 for ; Tue, 5 May 2020 15:49:47 +0000 (UTC) X-FDA: 76783100814.27.coal41_7289802fd1833 X-HE-Tag: coal41_7289802fd1833 X-Filterd-Recvd-Size: 5784 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 15:49:46 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id h4so2847947wmb.4 for ; Tue, 05 May 2020 08:49:46 -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=xduNJNk72lfTzo2Qmvpc5OFvX5tJ6mFglpcx46T2q98=; b=bJO3UfWP1Ds/DcisVZuYm8xOpLOEZEaWAM3mydhwnGJvVTuLcsMdyLWfrWM83Kx+bb hXTohVxwM6mleEmctaE6eIyeM58jvrwBOLivnnVYh/uayOr8warNMDsZqMZGqCqr69H9 akW5Kvs6CV8r1eAZY9ONf675dkSx1B6DmfzkPcd7XQhp5k7j8IJNBKmNBGhpSv00W3sR I/gpaLAJ064M3oGNvilCJ2vD0stmYuKQ6mg4d7OZ8mNVjaS2BN/K6QX/K6tF136zWz+N uvkR6yHD7x0kKQo0ZAQpzwEhyvFxtXyiEXbllZ6YKqr5I6wZEULvwKQtPtAFWsdrQNL9 ysGg== X-Gm-Message-State: AGi0PuZ2wf+bAwwgcHm2vei0TJe7AwM0tyt/ck2bFRt0gh+nKCGgulxO g0End7xLU53ZPKEdN9ssbtY= X-Google-Smtp-Source: APiQypJjEcrRcBT3LAv7V6UcyX48IsZBqT8tBP0izJb0ESRiEEAZy28VRx0LO7yBVK/IWaJoVVZDeg== X-Received: by 2002:a1c:1dc3:: with SMTP id d186mr3955032wmd.90.1588693785850; Tue, 05 May 2020 08:49:45 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id h10sm3891154wrv.29.2020.05.05.08.49.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 08:49:44 -0700 (PDT) Date: Tue, 5 May 2020 17:49:43 +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: <20200505154943.GR16322@dhcp22.suse.cz> References: <20200504065600.GA22838@dhcp22.suse.cz> <20200504141136.GR22838@dhcp22.suse.cz> <20200504150052.GT22838@dhcp22.suse.cz> <20200504160613.GU22838@dhcp22.suse.cz> <20200505152712.GB58018@cmpxchg.org> 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 Tue 05-05-20 08:35:45, Shakeel Butt wrote: > On Tue, May 5, 2020 at 8:27 AM Johannes Weiner wrote: > > > > On Mon, May 04, 2020 at 12:23:51PM -0700, Shakeel Butt wrote: > > > On Mon, May 4, 2020 at 9:06 AM Michal Hocko wrote: > > > > I really hate to repeat myself but this is no different from a regular > > > > oom situation. > > > > > > Conceptually yes there is no difference but there is no *divine > > > restriction* to not make a difference if there is a real world > > > use-case which would benefit from it. > > > > I would wholeheartedly agree with this in general. > > > > However, we're talking about the very semantics that set memory.max > > apart from memory.high: triggering OOM kills to enforce the limit. > > > > > > 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. > > > > > > *Potentially* useful for debugging versus actually beneficial for > > > "sweep before tear down" use-case. Also I am not saying to make "no > > > dumps for memory.max when no eligible tasks" a set in stone rule. We > > > can always reevaluate when such information will actually be useful. > > > > > > Johannes/Andrew, what's your opinion? > > > > I still think that if you want to sweep without triggering OOMs, > > memory.high has the matching semantics. > > > > As you pointed out, it doesn't work well for foreign charges, but that > > is more of a limitation in the implementation than in the semantics: > > > > /* > > * If the hierarchy is above the normal consumption range, schedule > > * reclaim on returning to userland. We can perform reclaim here > > * if __GFP_RECLAIM but let's always punt for simplicity and so that > > * GFP_KERNEL can consistently be used during reclaim. @memcg is > > * not recorded as it most likely matches current's and won't > > * change in the meantime. As high limit is checked again before > > * reclaim, the cost of mismatch is negligible. > > */ > > > > Wouldn't it be more useful to fix that instead? It shouldn't be much > > of a code change to do sync reclaim in try_charge(). > > Sync reclaim would really simplify the remote charging case. Though > should sync reclaim only be done for remote charging or for all? The simplest way around that would be to always do sync reclaim for unpopulated memcgs because those do not have any user context to reclaim from and for restricted allocation contexts like atomic allocations maybe also for GFP_NO{IO,FS}. -- Michal Hocko SUSE Labs