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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER,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 E2D7BC5519A for ; Fri, 24 Apr 2020 16:22:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9A70B2071E for ; Fri, 24 Apr 2020 16:22:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=fb.com header.i=@fb.com header.b="HvGwRzzX"; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.i=@fb.onmicrosoft.com header.b="FraxOTTP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A70B2071E Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=fb.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 395208E0009; Fri, 24 Apr 2020 12:22:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 344DA8E0003; Fri, 24 Apr 2020 12:22:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E6A88E0009; Fri, 24 Apr 2020 12:22:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 061E08E0003 for ; Fri, 24 Apr 2020 12:22:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A656F181AC9BF for ; Fri, 24 Apr 2020 16:22:08 +0000 (UTC) X-FDA: 76743265536.07.ink24_2fbdcf56e5243 X-HE-Tag: ink24_2fbdcf56e5243 X-Filterd-Recvd-Size: 11589 Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Apr 2020 16:22:07 +0000 (UTC) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03OGJj8e008101; Fri, 24 Apr 2020 09:22:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=facebook; bh=U+jURu/ME4WibFg2YveaZlKwGlJ+z6u9FrSKBpzlEMw=; b=HvGwRzzXjPNUZDCXwGn+197VeaqpyEvlnD84GIlIDEfKy/JsRg7vhl4vGQed8igOORsX dArDXMv6LdcYNmTYarbAJc8zwfwsGFsM2CAujlBH39KaQn7qWS7RFq+7BoJ1AzcdAjC+ Zzue+3PijbYY1FeL4XqK8dSbWRYwcvZntZ8= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 30jwf0vv5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 24 Apr 2020 09:22:02 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 24 Apr 2020 09:22:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AF0XtpTC4jMPpAlEClDBQimOm4L5pGlmdJ+2ZGZ230jyXn1jtzgxIdH29r9lorVDj8UahKUIW/zbpMK1J7ZJRTIqBnc4T69JIoLnhHU7F5dmOH8HQsU5r/PfEVlCKHFYJqZd33aW+K1/VsLrrRBdffpF67iImfO/ZpoE89rLCbBJ5pZzoSf8zuzzTjIGwA+Xz41LRYpQL6zK7AQGqvhgWiEE1LgZh42xMU79hOUI43C92GPvzbOyTnVv1A+UHha2S1ZqPUWzMeajB1MuNZrnTameNuBfHRAI8pOgGJL7oTCRNG4dyIHg6qdwfeGda1o2yRZjEIIQh87RUCJ/EZRRng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U+jURu/ME4WibFg2YveaZlKwGlJ+z6u9FrSKBpzlEMw=; b=kEhqbQXRvRtlQJsr8XE8M887iU6hOn8NI6W1CZt4zpKDfQQakMoSXf/iI3zLo8aj0bQoLd0Ek9hP4E5Y0AsUmHfKh5BSvGO9PvtyIcw0RQX2eDKHzP57dTYZMV5H5sx+N3GVwAvTMVFuUHWh6OeGP1NLVvfT87qqBWGVd5nmnJfbeSM2fMboC81WRXdkO4Cb2uYDPvvA4C+n8+YGCzpJGP0FPISwkK6pReWYf2FC9MD6iFNuwIveBJ+6jMHuw5MGUHNzU0Uudt8GtoZUg5Q1iNIkVZ1DbhnttMkbB7Gix0DKAfgOVK8b7ucJGox8W7IJOgBJZfkJ7N4Iyn0TMXlK4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U+jURu/ME4WibFg2YveaZlKwGlJ+z6u9FrSKBpzlEMw=; b=FraxOTTPTMs+eYwoQ7PFR7x4ASDo4gN49XpL5Xv3qYKjxM+lI+BmzkVhqv2OApYQbPCNFSLvxDP6Wd9TGiC4jXRZqNnjsEZmyxGa3lJLhHi0iG44uLn/c1YNcHlDKGMD+DdkLCea7UFPzA5Y3C0irFm6OAqxUiGtzbRstaMWEOU= Received: from BYAPR15MB4136.namprd15.prod.outlook.com (2603:10b6:a03:96::24) by BYAPR15MB2519.namprd15.prod.outlook.com (2603:10b6:a03:14f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 24 Apr 2020 16:21:53 +0000 Received: from BYAPR15MB4136.namprd15.prod.outlook.com ([fe80::bdf9:6577:1d2a:a275]) by BYAPR15MB4136.namprd15.prod.outlook.com ([fe80::bdf9:6577:1d2a:a275%7]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 16:21:53 +0000 Date: Fri, 24 Apr 2020 09:21:48 -0700 From: Roman Gushchin To: Michal Hocko CC: Johannes Weiner , Yafang Shao , , , , Chris Down , Subject: Re: [PATCH] mm, memcg: fix wrong mem cgroup protection Message-ID: <20200424162148.GA99424@carbon.lan> References: <20200423061629.24185-1-laoar.shao@gmail.com> <20200424131450.GA495720@cmpxchg.org> <20200424142958.GF11591@dhcp22.suse.cz> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200424142958.GF11591@dhcp22.suse.cz> X-ClientProxiedBy: CO2PR04CA0069.namprd04.prod.outlook.com (2603:10b6:102:1::37) To BYAPR15MB4136.namprd15.prod.outlook.com (2603:10b6:a03:96::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from carbon.lan (2620:10d:c090:400::5:1ddb) by CO2PR04CA0069.namprd04.prod.outlook.com (2603:10b6:102:1::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 16:21:52 +0000 X-Originating-IP: [2620:10d:c090:400::5:1ddb] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c9b0682f-14c9-4012-9199-08d7e86b998d X-MS-TrafficTypeDiagnostic: BYAPR15MB2519: X-Microsoft-Antispam-PRVS: X-FB-Source: Internal X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 03838E948C X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR15MB4136.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10019020)(366004)(376002)(346002)(396003)(39860400002)(136003)(4326008)(6916009)(8676002)(7696005)(66556008)(6666004)(66946007)(478600001)(54906003)(55016002)(81156014)(9686003)(5660300002)(33656002)(66476007)(86362001)(52116002)(1076003)(6506007)(186003)(36756003)(8936002)(2906002)(16526019)(316002)(8886007);DIR:OUT;SFP:1102; Received-SPF: None (protection.outlook.com: fb.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: b/u94YVQ31yy/owv8efuvuDKzDXvAwrbwnSXhP0PBYvTXrNnbGEYK+AnmIDiv3/xl1RWWZVgQB/oL4A45j6gF3Jd639KRQ7VPsgkI0QS21gwDbYSEbEH5vQU8nHJAU6WcTSGpTthquLush1qZfXsMTqVLee/PEaqvx7sRlrOMg3QUzrcTnmF1A4Kgy/hVfKspw9vmq0eESHLDHCSLs1OWrvZgHdfo3uDdwQXVn0nvd8BtVgtdaE0qyF7iFIO0m5lOTkDomdS+cMng5CFZkuN8JRrnvTGf/NcFwrbwXowZGYKAuGLSFgMJhx7/tNlgDY1ltQy7carYb9hGI+UfV9bK/H0JJwRKIaSjqoALnb3nCUtiPr71u7rXetQnxCKp3ob7rUYWFu/RJK+f+ftcZwqVgeGgInJL4S3cUo1v2jao6j8dWMCm8JnShJUZJtEzJEo X-MS-Exchange-AntiSpam-MessageData: At+ZDDQr626gbgS2ruvY+Be10gZBJytp8hAm4m1B/kfrFzch/m/3DREa7mtAGGv9pZKjOgQJv62MvrELU6r1TFtZXiDsEws5kSsbN/iNnGzs4prz/h9R5+8oQxho7xkfLzWxPrcITk48qHlgn88+YA7Q+txEaGzGLYkL1DRLM8M+BS2xmbdjLzXbUeM64G1h X-MS-Exchange-CrossTenant-Network-Message-Id: c9b0682f-14c9-4012-9199-08d7e86b998d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 16:21:53.5668 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jAEerd+uMH2KYT+JJNsdYePOlLHVsBC1LCpNv59ggxofZkkAy1VwzC8LQ5fvB3WI X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2519 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-24_08:2020-04-24,2020-04-24 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 bulkscore=0 spamscore=0 clxscore=1015 adultscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 suspectscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004240127 X-FB-Internal: deliver 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 Fri, Apr 24, 2020 at 04:29:58PM +0200, Michal Hocko wrote: > On Fri 24-04-20 09:14:50, Johannes Weiner wrote: > > On Thu, Apr 23, 2020 at 02:16:29AM -0400, Yafang Shao wrote: > > > This patch is an improvement of a previous version[1], as the previous > > > version is not easy to understand. > > > This issue persists in the newest kernel, I have to resend the fix. As > > > the implementation is changed, I drop Roman's ack from the previous > > > version. > > > > Now that I understand the problem, I much prefer the previous version. > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 745697906ce3..2bf91ae1e640 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -6332,8 +6332,19 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root, > > > > if (!root) > > root = root_mem_cgroup; > > - if (memcg == root) > > + if (memcg == root) { > > + /* > > + * The cgroup is the reclaim root in this reclaim > > + * cycle, and therefore not protected. But it may have > > + * stale effective protection values from previous > > + * cycles in which it was not the reclaim root - for > > + * example, global reclaim followed by limit reclaim. > > + * Reset these values for mem_cgroup_protection(). > > + */ > > + memcg->memory.emin = 0; > > + memcg->memory.elow = 0; > > return MEMCG_PROT_NONE; > > + } > > Could you be more specific why you prefer this over the > mem_cgroup_protection which doesn't change the effective value? > Isn't it easier to simply ignore effective value for the reclaim roots? Hm, I think I like the new version better, because it feels "safer" in terms of preserving sane effective protection values for concurrent reclaimers. > > [...] > > > As others have noted, it's fairly hard to understand the problem from > > the above changelog. How about the following: > > > > 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. > > > > 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. > > This is better. Thanks! +1 and I like the proposed renaming/cleanup. Thanks, Johannes! > > > 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. > > I do not see how this would lead all the way to OOM killer but it > certainly can lead to unnecessary increase of the reclaim priority. The > smaller the difference between the reclaim target and protection the > more visible the effect would be. But if there are reclaimable pages > then the reclaim should see them sooner or later I guess if all memory is protected by emin and the targeted reclaim will be unable to reclaim anything, OOM can be triggered. Btw, I wonder if this case can be covered by a new memcg kselftest? I'm not sure it can be easily reproducible, but if it can, it would be the best demonstration of a problem and the fix. Yafang, don't you want to try? Thanks!