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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,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 93540C83000 for ; Wed, 29 Apr 2020 14:19:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 575D820B80 for ; Wed, 29 Apr 2020 14:19:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="sM10OsRR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 575D820B80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B62B38E0008; Wed, 29 Apr 2020 10:19:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B11DA8E0005; Wed, 29 Apr 2020 10:19:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DA4F8E0008; Wed, 29 Apr 2020 10:19:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 82B4F8E0005 for ; Wed, 29 Apr 2020 10:19:48 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4FDE52C7C for ; Wed, 29 Apr 2020 14:19:48 +0000 (UTC) X-FDA: 76761101256.05.hat54_8fbcf33f02c4f X-HE-Tag: hat54_8fbcf33f02c4f X-Filterd-Recvd-Size: 6714 Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Apr 2020 14:19:47 +0000 (UTC) Received: by mail-qk1-f194.google.com with SMTP id l78so2080571qke.7 for ; Wed, 29 Apr 2020 07:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WY+s1xElLyYapOX+xyVfCwGq2ouDJfw9qAn8e1SedMM=; b=sM10OsRR0LNY4pcjhbdJnhoISXS/L4LnoeViGpuwZ2v+5WA8cDi0zGpia6vF/Lnywe 9yDC5Ysp9d3GxBOYO/Jy5r525crsR9ZR6Pel0O38S0Xl0kMiRfmh7zpL/aA3BBu81rMm tmR84XZpKOhWYZyP9PUd9L+TFewI/8EMjEjYSUpVDVJ6+3CAapKUaVFTXct61QYcva81 gvSR+ox35ebLokYCKn2R0DeTO0+BRyx56hxhXWqLfCHar8ss9urE1ne3VXSINkkEOwdA 5+q38c+uJC7z15wq2a3UQbl+6dVrM4vvJ4ZWX9Y2UXi2JxONkL/tF3icTij/9A/Vqv9y GtaQ== 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=WY+s1xElLyYapOX+xyVfCwGq2ouDJfw9qAn8e1SedMM=; b=co55tKTVg8//v0o/A6eq93EdqG5kk11OE7k9Q3FJdYcT+VtCaqbkLu8dsnHtgzKrJy FoGf9ZLPJcuyTr6SloSmNKPWQyLYwriQTmG3LKuqAmunugXidDeA1//2KSLPcZz/LK9s tEZO4u50FxFZTsFpZ5VtKk0aWGbQXmNBeOV57THU9DbElolcMLdBOWhV06GsKL4Tk9cU 9DdDRwRfijhU+blBnD2NLZmJ7VlFW8fZ+1T4GdOEIu9Y10/aOgJjyFaJkbVTRxvgO243 ze6iKxrclb8aL7l2xHo457uCP55ZynkXvBDJOuLzVEQfVvq+YMN5Up6rWmzOOVuh9naY wT6Q== X-Gm-Message-State: AGi0PubbyO+L38xt6tMAxCs0U7ha+mUDkRd1WKj65MXBnbm5sWmbb87/ QEXM14024bEGuXmM4r/ukrOSkQ== X-Google-Smtp-Source: APiQypKY1jxWzFUg/BqBWREV5gw+gcRj3d3DZwN6IsgBLMzwfxKXzASR4TlcBVu5Uaa4l1Z070vJPQ== X-Received: by 2002:a37:5102:: with SMTP id f2mr16575684qkb.18.1588169986863; Wed, 29 Apr 2020 07:19:46 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id k33sm15552796qtd.22.2020.04.29.07.19.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 07:19:46 -0700 (PDT) Date: Wed, 29 Apr 2020 10:19:45 -0400 From: Johannes Weiner To: Yafang Shao Cc: Michal Hocko , Chris Down , Andrew Morton , Roman Gushchin , Linux MM , Cgroups , LKML Subject: Re: [PATCH 1/2] mm, memcg: Avoid stale protection values when cgroup is above protection Message-ID: <20200429141945.GB5054@cmpxchg.org> References: <20200429101510.GA28637@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 Wed, Apr 29, 2020 at 06:53:03PM +0800, Yafang Shao wrote: > On Wed, Apr 29, 2020 at 6:15 PM Michal Hocko wrote: > > > > On Tue 28-04-20 19:26:47, Chris Down wrote: > > > From: Yafang Shao > > > > > > A cgroup can have both memory protection and a memory limit to isolate > > > it from its siblings in both directions - for example, to prevent it > > > from being shrunk below 2G under high pressure from outside, but also > > > from growing beyond 4G under low pressure. > > > > > > Commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") > > > implemented proportional scan pressure so that multiple siblings in > > > excess of their protection settings don't get reclaimed equally but > > > instead in accordance to their unprotected portion. > > > > > > During limit reclaim, this proportionality shouldn't apply of course: > > > there is no competition, all pressure is from within the cgroup and > > > should be applied as such. Reclaim should operate at full efficiency. > > > > > > However, mem_cgroup_protected() never expected anybody to look at the > > > effective protection values when it indicated that the cgroup is above > > > its protection. As a result, a query during limit reclaim may return > > > stale protection values that were calculated by a previous reclaim cycle > > > in which the cgroup did have siblings. > > > > > > When this happens, reclaim is unnecessarily hesitant and potentially > > > slow to meet the desired limit. In theory this could lead to premature > > > OOM kills, although it's not obvious this has occurred in practice. > > > > Thanks this describes the underlying problem. I would be also explicit > > that the issue should be visible only on tail memcgs which have both > > max/high and protection configured and the effect depends on the > > difference between the two (the smaller it is the largrger the effect). > > > > There is no mention about the fix. The patch resets effective values for > > the reclaim root and I've had some concerns about that > > http://lkml.kernel.org/r/20200424162103.GK11591@dhcp22.suse.cz. > > Johannes has argued that other races are possible and I didn't get to > > think about it thoroughly. But this patch is introducing a new > > possibility of breaking protection. > > Agreed with Michal that more writes will cause more bugs. > We should operate the volatile emin and elow as less as possible. That's not a technical argument. If races are a problem, it doesn't matter that they're rare. If they're not a problem, it doesn't matter that they're frequent. > > If we want to have a quick and > > simple fix that would be easier to backport to older kernels then I > > would feel much better if we simply workedaround the problem as > > suggested earlier http://lkml.kernel.org/r/20200423061629.24185-1-laoar.shao@gmail.com > > +1 > > This should be the right workaround to fix the current issue and it is > worth to be backported to the stable kernel. >From Documentation/process/stable-kernel-rules.rst: - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing). There hasn't been a mention of this affecting real workloads in the submission history of this patch, so it doesn't qualify for -stable.