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 B6D5FC433DF for ; Mon, 17 Aug 2020 17:23:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8533A20738 for ; Mon, 17 Aug 2020 17:23:27 +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 S2389903AbgHQRXX (ORCPT ); Mon, 17 Aug 2020 13:23:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389197AbgHQQ4M (ORCPT ); Mon, 17 Aug 2020 12:56:12 -0400 Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBE47C061344 for ; Mon, 17 Aug 2020 09:56:11 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id i20so1354356qkk.8 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=VWIuqotNYaY5ADFqiKG+H2Qxj2BLEdVygwtBz3oS1TnkOW3FMQejR5sDTkdYKfg76M B70hGsXn8uFEUQfUdU+m88TJVkRxdNH0iNJAiCg/Yk0E2HXHMW/gVCjsknsJDi0db/qB AQ0gX3OWZkKIOg4lwmeoMe/znC8+b1+8i2fOx2HkzlQEdP9avSVCfdJdC4Zw2dz6VSPM Ew4Ub/W40daZl3BSa+Kxxe1dwzFQl3BtfE0aL8nCWMGQzTaStZ/GFpXyIeSGFvHKOe85 QtZmseWeSFElsGWm756vdUAFdNqYjGrK6yLYwpqhJ3Do6xobPgbP9nWE9jj3Q5b18ILI iSmg== X-Gm-Message-State: AOAM531z+JrxcEsDirJXNvKRoAmkNJrwRfq4BasUVHgMyMmufHZthtFO iG0PtTlvodcRFCGJ/B/Odua5Kg== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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? :-)