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=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 DE4D4C433E1 for ; Mon, 17 Aug 2020 17:33:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BBEAA2063A for ; Mon, 17 Aug 2020 17:33:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="e0lnhMNX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729650AbgHQRdA (ORCPT ); Mon, 17 Aug 2020 13:33:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389198AbgHQQ4M (ORCPT ); Mon, 17 Aug 2020 12:56:12 -0400 Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBD7FC061342 for ; Mon, 17 Aug 2020 09:56:11 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id b79so15562321qkg.9 for ; Mon, 17 Aug 2020 09:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Sre2n1Pi8KkTqGTv1s6yeby+p8079BRqjBOJcwiSLww=; b=e0lnhMNX4rbCpfxhO+gQeYAWXdMT9zu80lFA0njs6xwsW1qMBlgAAwdV2fB0ZrDmbI DJwU3H9e/x24KArsI3bcQm9YF2fnooWNYRP2u0lBlOJpfLosNy8hnAKjfFXmNtk1tfH5 iHxLc3XXadcqboQN3EKUpEvNmXTEMAqp2DHM4= 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:user-agent; bh=Sre2n1Pi8KkTqGTv1s6yeby+p8079BRqjBOJcwiSLww=; b=VBLfoFXsVvKGO84Cdi7u6bU8kfDx9awykJebXI4pLOrKz83VqynbiT7lJZmQ+AfszL nNMeZXxT1mEDlkrWtLZ7Rab8rxB78Y9pHklqCEHJml3QAowtdpF5EnQU2/LhbAHUuXFt alMQY49TEYLCbFrvU3g4BSc2d73P87sedVIY/FU8g8kJ1jb1jd4V1w/97xJAsrl21eUo zT7B4EBfAFi/tcJPfNG4wly/P0R4gJmJVC544OryJg424L2HdqLS5cJaueyy4gqGd4kz h2jblGbhCTdL1ePEsiq5EcQo0xJHtfTzAt7os/3qDPqDFBdmt8/d6tppBVUg8xrK5yE8 Uaww== X-Gm-Message-State: AOAM533TAj5TYwTNa5FREFcvI5sYem3ewploeeFkjwwv7Q7tLBskcnXi aYKZSp6jfgnhA/yIHAIaqUQ/8g== X-Google-Smtp-Source: ABdhPJxZri8aP3S0zZTZ5oc+FXv5KMWFUhk31+VgZOzDluuloBhLwcX29rp5YCOCLko4QBnQct7MsQ== X-Received: by 2002:a37:4144:: with SMTP id o65mr13531902qka.32.1597683370402; Mon, 17 Aug 2020 09:56:10 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:47cc]) by smtp.gmail.com with ESMTPSA id n184sm17781669qkn.49.2020.08.17.09.56.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2020 09:56:09 -0700 (PDT) Date: Mon, 17 Aug 2020 17:56:08 +0100 From: Chris Down To: Shakeel Butt Cc: Waiman Long , 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 Subject: Re: [RFC PATCH 1/8] memcg: Enable fine-grained control of over memory.high action Message-ID: <20200817165608.GA58383@chrisdown.name> References: <20200817140831.30260-1-longman@redhat.com> <20200817140831.30260-2-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.14.6 (2020-07-11) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Shakeel Butt writes: >> 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? Oh, thanks Shakeel for bringing this up. I missed this in the original changelog and I'm surprised that it's mentioned, since we do have protections against that. Waiman, we already added artificial throttling if memory reclaim is not sufficiently achieved in 0e4b01df8659 ("mm, memcg: throttle allocators when failing reclaim over memory.high"), which has been present since v5.4. This should significantly inhibit physical memory consumption from increasing. What problems are you having with that? :-)