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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 6A232C433E1 for ; Mon, 17 Aug 2020 16:44:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 039D220674 for ; Mon, 17 Aug 2020 16:44:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="c+qkjdRR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 039D220674 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 65D396B0006; Mon, 17 Aug 2020 12:44:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E5CA6B0008; Mon, 17 Aug 2020 12:44:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D5996B000A; Mon, 17 Aug 2020 12:44:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id 385B16B0006 for ; Mon, 17 Aug 2020 12:44:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E189A45BB for ; Mon, 17 Aug 2020 16:44:55 +0000 (UTC) X-FDA: 77160634950.03.trade15_0d0af6427018 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id A6D4B28A4EA for ; Mon, 17 Aug 2020 16:44:55 +0000 (UTC) X-HE-Tag: trade15_0d0af6427018 X-Filterd-Recvd-Size: 4199 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Aug 2020 16:44:55 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id t23so18236506ljc.3 for ; Mon, 17 Aug 2020 09:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ustc/Co8E0AQhbcerO/qjyS5RAvKGH1AciZ7eOvqsmA=; b=c+qkjdRRVAF0xvWA9+DkkVLwK7sGF1z8hQM3CtGa1YD+bJI6w1nj5+9S70Q8FvCQqi 2Ei0s13pec+cTVm+0OSOFIdw7vP7XLcSIvUcZ6EGrALSHKiZ7PPGzM4XEb029aajiYyC aEhBUOpbzPBTQSG4Cdn7X1BjMfLQqn745I4HqH3Abk31kJgYxjgeUpKk7qwB2tzxmqpe AtkUyANm5zAbjaLbrp8RlEB5I2UccCxi0HQae47ThK7uHUPNGSHd8fX+Y3ltxcsiL9Kl 3ENiFhFOnYGf8LXV3bRXJi1SUgcycpC5v7MIYDrXtB34VmBj+Nk2YpIHRR25BtbB6i8Q lRBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ustc/Co8E0AQhbcerO/qjyS5RAvKGH1AciZ7eOvqsmA=; b=c69VIeq8mJs+p8MGKsLWrEjWkyFW9sbtnqsc0+1Zax5HnUvyYVoN5jhCgkS5nnHUTB BkWeqvYloKzZ9xwh2PofFvsszlrD2iK7FbEBhCmbmFrqsDRe1EPv9NET0DRjEXMut8vj bJ75mO7LBGLFrNwhNkKUTKQa1q7No3cnAkg12MqrVH70y7DrjRX3caszh6/b4QczDY9z acls8QQFW9Ajaq5UcJrt1QV7a3vpRKa6mIvxp7PrjIMGDEVnsxiUyykRJ/vTZFgmGe0/ YNKqicAe8EuBMCsxhZN/XC8OiYmHDlyJYCPiet1caCbvHSVcIQOTna8ZuyFW5PAq0ELB 0fnA== X-Gm-Message-State: AOAM531ULHHh6RM+KHKG2Dz8S1Ia537x6PsSnJJY0Md0+uFa0TYcs58E a3FlD3tWwKRc8bMPiA2WMUumZJNkES6JYDa8cyqW1w== X-Google-Smtp-Source: ABdhPJxOE/KUm/g/wNOBiL7kHkyu0ap1d61VlZFxn7CVZ1FQIRsBFPdNAO+qmD/8YZJURfdVWZ4NywWAdRo3uSnMkE4= X-Received: by 2002:a2e:96c3:: with SMTP id d3mr7974441ljj.270.1597682693369; Mon, 17 Aug 2020 09:44:53 -0700 (PDT) MIME-Version: 1.0 References: <20200817140831.30260-1-longman@redhat.com> <20200817140831.30260-2-longman@redhat.com> In-Reply-To: <20200817140831.30260-2-longman@redhat.com> From: Shakeel Butt Date: Mon, 17 Aug 2020 09:44:42 -0700 Message-ID: Subject: Re: [RFC PATCH 1/8] memcg: Enable fine-grained control of over memory.high action To: Waiman Long Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , Jonathan Corbet , Alexey Dobriyan , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , LKML , linux-doc@vger.kernel.org, linux-fsdevel , Cgroups , Linux MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A6D4B28A4EA X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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, Aug 17, 2020 at 7:11 AM Waiman Long wrote: > > Memory controller can be used to control and limit the amount of > physical memory used by a task. When a limit is set in "memory.high" > in a non-root memory cgroup, the memory controller will try to reclaim > memory if the limit has been exceeded. Normally, that will be enough > to keep the physical memory consumption of tasks in the memory cgroup > to be around or below the "memory.high" limit. > > Sometimes, memory reclaim may not be able to recover memory in a rate > that can catch up to the physical memory allocation rate especially > when rotating disks are used for swapping or writing dirty pages. In > this case, the physical memory consumption will keep on increasing. Isn't this the real underlying issue? Why not make the guarantees of memory.high more strict instead of adding more interfaces and complexity? By the way, have you observed this issue on real workloads or some test cases? It would be good to get a repro with simple test cases.