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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63058C433F5 for ; Thu, 7 Apr 2022 07:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241922AbiDGHiJ (ORCPT ); Thu, 7 Apr 2022 03:38:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241963AbiDGHhd (ORCPT ); Thu, 7 Apr 2022 03:37:33 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B95C74DF4A; Thu, 7 Apr 2022 00:35:33 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 0340B21122; Thu, 7 Apr 2022 07:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649316932; h=from:from:reply-to: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=4+V8CVr+PsVvoMRvSRXz1QR100B6sh+pY7exh4j2aBc=; b=o5iaBUNZARcTgJe1NnxGXMIcqlgmG9bsli9PzpUf7DjbZ8YS1jF7HF8ooX2hVuDm3lyZSN 2DcYNmsVkwM1UhSNWQUsfsKBwgNocKT+VvJEyTI9AdJ7C8TBU5Lr4WzrxrVrdBGzBPvhW6 yBNJheAWgva8zVizVPCwPxEe5A7T1F0= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id F2B1CA3B83; Thu, 7 Apr 2022 07:35:26 +0000 (UTC) Date: Thu, 7 Apr 2022 09:35:30 +0200 From: Michal Hocko To: "Huang, Ying" Cc: Wei Xu , Yosry Ahmed , Johannes Weiner , Shakeel Butt , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , Cgroups , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Linux MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Greg Thelen , Tim Chen Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface Message-ID: References: <20220331084151.2600229-1-yosryahmed@google.com> <87y20nzyw4.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o81fujdc.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkxfudrk.fsf@yhuang6-desk2.ccr.corp.intel.com> <877d82vi13.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877d82vi13.fsf@yhuang6-desk2.ccr.corp.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 06-04-22 14:32:24, Huang, Ying wrote: [...] > I think we should define the interface not from the current > implementation point of view, but from the requirement point of view. Agreed! > For proactive reclaim, per my understanding, the requirement is, > > we found that there's some cold pages in some workloads, so we can > take advantage of the proactive reclaim to reclaim some pages so that > other workload can use the freed memory. We are talking about memcg here so this is not as much a matter of free memory as it is to decrease the amount of charged memory. Demotion cannot achieve that. > For proactive demotion, per my understanding, the requirement could be, > > We found that there's some cold pages in fast memory (e.g. DRAM) in > some workloads, so we can take advantage of the proactive demotion to > demote some pages so that other workload can use the freed fast > memory. Given the DRAM partition support Tim (Cced) is working on. Yes, this is essentially a kernel assisted memory migration. Userspace can migrate memory but the issue is that it doesn't have any information on the aging so the migration has hard time to find suitable memory to migrate. If we really need this functionality then it would deserve a separate interface IMHO. -- Michal Hocko SUSE Labs