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=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 30913C433DF for ; Tue, 18 Aug 2020 10:31:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 01EA92075E for ; Tue, 18 Aug 2020 10:31:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01EA92075E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 801978D0008; Tue, 18 Aug 2020 06:31:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7634A8D0003; Tue, 18 Aug 2020 06:31:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DCA28D0008; Tue, 18 Aug 2020 06:31:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 476C88D0003 for ; Tue, 18 Aug 2020 06:31:02 -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 02773824556B for ; Tue, 18 Aug 2020 10:31:02 +0000 (UTC) X-FDA: 77163321564.04.bell24_3c030d92701e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id BE79B8007DD2 for ; Tue, 18 Aug 2020 10:31:01 +0000 (UTC) X-HE-Tag: bell24_3c030d92701e X-Filterd-Recvd-Size: 2799 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Aug 2020 10:31:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B3221AF8E; Tue, 18 Aug 2020 10:31:25 +0000 (UTC) Date: Tue, 18 Aug 2020 12:30:59 +0200 From: Michal Hocko To: peterz@infradead.org Cc: 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: <20200818103059.GP28270@dhcp22.suse.cz> 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> <20200818100516.GO28270@dhcp22.suse.cz> <20200818101844.GO2674@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200818101844.GO2674@hirez.programming.kicks-ass.net> X-Rspamd-Queue-Id: BE79B8007DD2 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 Tue 18-08-20 12:18:44, Peter Zijlstra wrote: > On Tue, Aug 18, 2020 at 12:05:16PM +0200, Michal Hocko wrote: > > > But then how can it run-away like Waiman suggested? > > > > As Chris mentioned in other reply. This functionality is quite new. > > > > > /me goes look... and finds MEMCG_MAX_HIGH_DELAY_JIFFIES. > > > > We can certainly tune a different backoff delays but I suspect this is > > not the problem here. > > Tuning? That thing needs throwing out, it's fundamentally buggered. Why > didn't anybody look at how the I/O drtying thing works first? > > What you need is a feeback loop against the rate of freeing pages, and > when you near the saturation point, the allocation rate should exactly > match the freeing rate. > > But this thing has nothing what so ever like that. Existing usecases seem to be doing fine with the existing implementation. If we find out that this is insufficient then we can work on that but I believe this is tangent to this email thread. There are no indications that the current implementation doesn't throttle enough. The proposal also aims at much richer interface to define the oom behavior. -- Michal Hocko SUSE Labs