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.9 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 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 C5FEDC2D0E2 for ; Tue, 22 Sep 2020 19:09:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 395462311C for ; Tue, 22 Sep 2020 19:09:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="am3UrXxd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 395462311C Authentication-Results: mail.kernel.org; dmarc=fail (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 5E6116B0003; Tue, 22 Sep 2020 15:09:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 56F116B0055; Tue, 22 Sep 2020 15:09:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EC426B005A; Tue, 22 Sep 2020 15:09:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id 2281C6B0003 for ; Tue, 22 Sep 2020 15:09:03 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D63F53630 for ; Tue, 22 Sep 2020 19:09:02 +0000 (UTC) X-FDA: 77291634924.13.apple89_600281327150 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id AA45418140B67 for ; Tue, 22 Sep 2020 19:09:02 +0000 (UTC) X-HE-Tag: apple89_600281327150 X-Filterd-Recvd-Size: 3967 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 19:09:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1600801740; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CW9QWqJ7q2Kodf4xbjqeZQdYjMsmJi312d4fCh2gG6g=; b=am3UrXxd1MkIUqFBP8aN0slqcWO/Bw63BGSak3pgn1ZPDR8+wNqHKX9srRcZzat4AJ+akz SCCnb2Z4J5dh68Go3WrUZxK/OxrQkwsnTsPrRVAYgMYIFcV2MEkhUwEVgvF23+89DXxAHS Q9tXE/PSUecByYAItejjA5fw1Q82EHg= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B568AADB3; Tue, 22 Sep 2020 19:09:37 +0000 (UTC) Date: Tue, 22 Sep 2020 21:08:59 +0200 From: Michal Hocko To: Shakeel Butt Cc: Minchan Kim , Johannes Weiner , Roman Gushchin , Greg Thelen , David Rientjes , Michal =?iso-8859-1?Q?Koutn=FD?= , Andrew Morton , Linux MM , Cgroups , LKML , Yang Shi Subject: Re: [PATCH] memcg: introduce per-memcg reclaim interface Message-ID: <20200922190859.GH12990@dhcp22.suse.cz> References: <20200909215752.1725525-1-shakeelb@google.com> <20200921163055.GQ12990@dhcp22.suse.cz> <20200922114908.GZ12990@dhcp22.suse.cz> <20200922165527.GD12990@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 22-09-20 11:10:17, Shakeel Butt wrote: > On Tue, Sep 22, 2020 at 9:55 AM Michal Hocko wrote: [...] > > Last but not least the memcg > > background reclaim is something that should be possible without a new > > interface. > > So, it comes down to adding more functionality/semantics to > memory.high or introducing a new simple interface. I am fine with > either of one but IMO convoluted memory.high might have a higher > maintenance cost. One idea would be to schedule a background worker (which work on behalf on the memcg) to do the high limit reclaim with high limit target as soon as the high limit is reached. There would be one work item for each memcg. Userspace would recheck the high limit on return to the userspace and do the reclaim if the excess is larger than a threshold, and sleep as the fallback. Excessive consumers would get throttled if the background work cannot keep up with the charge pace and most of them would return without doing any reclaim because there is somebody working on their behalf - and is accounted for that. The semantic of high limit would be preserved IMHO because high limit is actively throttled. Where that work is done shouldn't matter as long as it is accounted properly and memcg cannot outsource all the work to the rest of the system. Would something like that (with many details to be sorted out of course) be feasible? If we do not want to change the existing semantic of high and want a new api then I think having another limit for the background reclaim then that would make more sense to me. It would resemble the global reclaim and kswapd model and something that would be easier to reason about. Comparing to echo $N > reclaim which might mean to reclaim any number pages around N. -- Michal Hocko SUSE Labs