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,URIBL_BLOCKED,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 BBD5AC433E1 for ; Tue, 18 Aug 2020 10:35:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7E9F2204EA for ; Tue, 18 Aug 2020 10:35:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="D+AXs5u4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E9F2204EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 407368D0009; Tue, 18 Aug 2020 06:35:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B7478D0002; Tue, 18 Aug 2020 06:35:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CE8E8D0009; Tue, 18 Aug 2020 06:35:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 142C68D0002 for ; Tue, 18 Aug 2020 06:35:43 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CBFAE824556B for ; Tue, 18 Aug 2020 10:35:42 +0000 (UTC) X-FDA: 77163333324.04.bulb97_3005bd92701e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 8BC75800B1E0 for ; Tue, 18 Aug 2020 10:35:42 +0000 (UTC) X-HE-Tag: bulb97_3005bd92701e X-Filterd-Recvd-Size: 5464 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Aug 2020 10:35:42 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id 77so17725232qkm.5 for ; Tue, 18 Aug 2020 03:35:41 -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=Qlc8i4WcaLGzjuzLCQuYqKKSVFT1SJwivNfqZW5VqT4=; b=D+AXs5u4icCFXOrccNIya9OfdiSVGHptiCbS4U4MtOZK/btvSa9eX8FVKZBh1negDV FemQeVyJCt8wUbC+K0euzqx7jvOmXbQm5Dn3nJcMx6aDQnmw0A/HkuGACqgYd2kPfJiG vdcnekXyohzB2PvtYEUWuln9SFWFdhspRM8oM= 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=Qlc8i4WcaLGzjuzLCQuYqKKSVFT1SJwivNfqZW5VqT4=; b=pyVc9f55BYqDFq2OkFcTyjW7um4y4Z4t2adIu3AxXrZHu099ylwoh/xZ3M+xn0BfzE 6sBYvxwsgfq4/txZK1PpmFSJMOvdq5vVIYZyEVlby6CULxZ+WdLYYz/hbBPF6+ETpRz5 mB1PCe6K+pVEdIOCph55h1253dUkQzUI1+9TdIjGmPFkvkcqBLbCbNE7xazyEwG/j1no 9KoELe1CMlxeKopi+aHSB69RlLwHcgvww1BjYdurWdltheZCG0qapu+p5xoh60QbZH/N G+OQ81uy/Vj3tt31w/IBcfPKeeh8hATazkEKqYqCyUVTxhuM7qBZFD9fNmBH7LYGA9Ub A8tA== X-Gm-Message-State: AOAM532fhxfa7PZByokiQ+JxOatThRK7IWM5n5Yj5cL0NWCw/e23V5Ea 20R2lScTMQzkXSWvIO2hGwlbZw== X-Google-Smtp-Source: ABdhPJyP9123mjcEB4Gacb/otH7/RlkpFN/q342fEZhyE2JQ0hS+aZmtOxf4Y511PcIOlkRd899Dhw== X-Received: by 2002:a37:9c6:: with SMTP id 189mr16374124qkj.122.1597746941391; Tue, 18 Aug 2020 03:35:41 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:179c]) by smtp.gmail.com with ESMTPSA id n6sm18455790qkh.74.2020.08.18.03.35.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2020 03:35:40 -0700 (PDT) Date: Tue, 18 Aug 2020 11:35:39 +0100 From: Chris Down To: peterz@infradead.org Cc: Michal Hocko , Waiman Long , Andrew Morton , Johannes Weiner , Vladimir Davydov , Jonathan Corbet , Alexey Dobriyan , Ingo Molnar , Juri Lelli , Vincent Guittot , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/8] memcg: Enable fine-grained per process memory control Message-ID: <20200818103539.GA156577@chrisdown.name> References: <20200817140831.30260-1-longman@redhat.com> <20200818091453.GL2674@hirez.programming.kicks-ass.net> <20200818092617.GN28270@dhcp22.suse.cz> <20200818095910.GM2674@hirez.programming.kicks-ass.net> <20200818101756.GA155582@chrisdown.name> <20200818102616.GP2674@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200818102616.GP2674@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.14.6 (2020-07-11) X-Rspamd-Queue-Id: 8BC75800B1E0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.004957, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: peterz@infradead.org writes: >On Tue, Aug 18, 2020 at 11:17:56AM +0100, Chris Down wrote: > >> I'd ask that you understand a bit more about the tradeoffs and intentions of >> the patch before rushing in to declare its failure, considering it works >> just fine :-) >> >> Clamping the maximal time allows the application to take some action to >> remediate the situation, while still being slowed down significantly. 2 >> seconds per allocation batch is still absolutely plenty for any use case >> I've come across. If you have evidence it isn't, then present that instead >> of vague notions of "wrongness". > >There is no feedback from the freeing rate, therefore it cannot be >correct in maintaining a maximum amount of pages. memory.high is not about maintaining a maximum amount of pages. It's strictly best-effort, and the ramifications of a breach are typically fundamentally different than for dirty throttling. >0.5 pages / sec is still non-zero, and if the free rate is 0, you'll >crawl across whatever limit was set without any bounds. This is math >101. > >It's true that I haven't been paying attention to mm in a while, but I >was one of the original authors of the I/O dirty balancing, I do think I >understand how these things work. You're suggesting we replace a well understood, easy to reason about model with something non-trivially more complex, all on the back of you suggesting that the current approach is "wrong" without any evidence or quantification. Peter, we're not going to throw out perfectly function memcg code simply because of your say so, especially when you've not asked for information or context about the tradeoffs involved, or presented any evidence that something perverse is actually happening. Prescribing a specific solution modelled on some other code path here without producing evidence or measurements specific to the nuances of this particular endpoint is not a recipe for success.