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.4 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 4E2F3C4363D for ; Mon, 5 Oct 2020 14:46:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B809920874 for ; Mon, 5 Oct 2020 14:46:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="hl2motqv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B809920874 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 02FCD6B006C; Mon, 5 Oct 2020 10:46:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFC4C6B0070; Mon, 5 Oct 2020 10:46:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC3BD6B0071; Mon, 5 Oct 2020 10:46:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id AD3B86B006C for ; Mon, 5 Oct 2020 10:46:15 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3280E824999B for ; Mon, 5 Oct 2020 14:46:15 +0000 (UTC) X-FDA: 77338147110.08.clock70_0502a00271be Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 080501819E785 for ; Mon, 5 Oct 2020 14:46:15 +0000 (UTC) X-HE-Tag: clock70_0502a00271be X-Filterd-Recvd-Size: 4717 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 14:46:14 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id 33so9631074edq.13 for ; Mon, 05 Oct 2020 07:46:14 -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=bJDWLFQK3NHbczue04Ad/oGIga5mw5RnC9F1EX3+XdE=; b=hl2motqvUtv+mvTksLda5r+AFkPsIl17oAkAoCpovuZwVAOmI4uF6k4X0hrbeu5UIV 4L63H25KQUKF8MNUkLWt/WneZgSx81pfLMMNxbhsI9ViwK7Q3zswPYsHmCMJd7yWREPt 5ZNnY8RT6kVH5ja7Img8nnNnLSz+y+pOeFYeo= 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=bJDWLFQK3NHbczue04Ad/oGIga5mw5RnC9F1EX3+XdE=; b=rlhfiiFBsKtwe/60WqXIcsEiuiKSp+5ERQxVj00embjpsKcxXP0bNtndO9E95nOHsS jM+CoFwz5A9jjJUn28rNNf702wEoPVVt8RGz53OE0jK4MZmwMI1/TiZwsokxpXocQsts 5pj3ROOUJ04hTsHLJPPiLgfkO4O6zpPqz5bgQCt0tTdxpRfBmjGmXuHlcXesOnYrzhro kJPNir5U+hHMCEC1GHJbfOBUgds2QThY4udXck6tVPO7fEmC9rmxlr0EXKvVK2KOsSL+ xdzl9dGQvRtrzjeuhLcOF6jmz1C6QaIrOuk1HxTFjoDI9JL3kKGTHlUWvwOsvEPEvXr+ QdHA== X-Gm-Message-State: AOAM530C305rvLTxYiP8OPX4doZf+54Vm7swFuBlv5/6IpdV5Q0vaBM2 7mHedDLa3aqwLhCeqA6HBebSXA== X-Google-Smtp-Source: ABdhPJx3qUGwmmpBOZFS45fQE04+dVbMCBwt75MdVDrLzDmAkcFM+DYTDIcRGfMI2aS/KZIlZn93kw== X-Received: by 2002:aa7:dd49:: with SMTP id o9mr16283240edw.331.1601909173219; Mon, 05 Oct 2020 07:46:13 -0700 (PDT) Received: from localhost ([2620:10d:c093:400::5:b1f1]) by smtp.gmail.com with ESMTPSA id a5sm36220edl.6.2020.10.05.07.46.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 07:46:12 -0700 (PDT) Date: Mon, 5 Oct 2020 15:46:12 +0100 From: Chris Down To: Andrea Righi Cc: Michal Hocko , Vladimir Davydov , Li Zefan , Tejun Heo , Johannes Weiner , Andrew Morton , Luigi Semenzato , "Rafael J . Wysocki" , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH RFC v2] Opportunistic memory reclaim Message-ID: <20201005144612.GB108347@chrisdown.name> References: <20201005081313.732745-1-andrea.righi@canonical.com> <20201005112555.GA108347@chrisdown.name> <20201005135130.GA850459@xps-13-7390> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20201005135130.GA850459@xps-13-7390> User-Agent: Mutt/1.14.7 (2020-08-29) 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: Andrea Righi writes: >senpai is focused at estimating the ideal memory requirements without >affecting performance. And this covers the use case about reducing >memory footprint. > >In my specific use-case (hibernation) I would let the system use as much >memory as possible if it's doing any activity (reclaiming memory only >when the kernel decides that it needs to reclaim memory) and apply a >more aggressive memory reclaiming policy when the system is mostly idle. From this description, I don't see any reason why it needs to be implemented in kernel space. All of that information is available to userspace, and all of the knobs are there. As it is I'm afraid of the "only when the system is mostly idle" comment, because it's usually after such periods that applications need to do large retrievals, and now they're going to be in slowpath (eg. periodic jobs). Such tradeoffs for a specific situation might be fine in userspace as a distribution maintainer, but codifying them in the kernel seems premature to me, especially for a knob which we will have to maintain forever onwards. >I could probably implement this behavior adjusting memory.high >dynamically, like senpai, but I'm worried about potential sudden large >allocations that may require to respond faster at increasing >memory.high. I think the user-space triggered memory reclaim approach is >a safer solution from this perspective. Have you seen Shakeel's recent "per-memcg reclaim interface" patches? I suspect they may help you there.