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.8 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 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 0B0B3C433B4 for ; Tue, 6 Apr 2021 09:08:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94D45613C3 for ; Tue, 6 Apr 2021 09:08:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94D45613C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine 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 E1C336B007E; Tue, 6 Apr 2021 05:08:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB86E6B0080; Tue, 6 Apr 2021 05:08:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C803A6B0081; Tue, 6 Apr 2021 05:08:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id AF5736B007E for ; Tue, 6 Apr 2021 05:08:45 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 638E2180ACEE8 for ; Tue, 6 Apr 2021 09:08:45 +0000 (UTC) X-FDA: 78001367010.36.8333761 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP id B693840002C2 for ; Tue, 6 Apr 2021 09:08:37 +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=1617700123; 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=+xOwykMT0eamXfCJ+cRJDX97KIiXiqqoybhZz05k4kE=; b=DtMYcBTnjx9dUFxs4dTtpXmx9nd/IwUaDXm0RMNwa/2CTUnx1EHnOMHwhshsRa+WrtKYf9 zl9eTafKeg9ZNn8OTE71ArZg20dckZXIftKR09DLkU1YtMmhZ8fg8QE3XeW2sfX3Y/yPG/ j/k4GeKheiATA6gmPjKWrmV6LCjiNQ4= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 99685B135; Tue, 6 Apr 2021 09:08:43 +0000 (UTC) Date: Tue, 6 Apr 2021 11:08:42 +0200 From: Michal Hocko To: Tim Chen Cc: Johannes Weiner , Andrew Morton , Dave Hansen , Ying Huang , Dan Williams , David Rientjes , Shakeel Butt , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 00/11] Manage the top tier memory in a tiered memory Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B693840002C2 X-Stat-Signature: t1bjku9wr1mi6nnegfuq47ape9tbom6e Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617700117-262969 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 Mon 05-04-21 10:08:24, Tim Chen wrote: [...] > To make fine grain cgroup based management of the precious top tier > DRAM memory possible, this patchset adds a few new features: > 1. Provides memory monitors on the amount of top tier memory used per cgroup > and by the system as a whole. > 2. Applies soft limits on the top tier memory each cgroup uses > 3. Enables kswapd to demote top tier pages from cgroup with excess top > tier memory usages. Could you be more specific on how this interface is supposed to be used? > This allows us to provision different amount of top tier memory to each > cgroup according to the cgroup's latency need. > > The patchset is based on cgroup v1 interface. One shortcoming of the v1 > interface is the limit on the cgroup is a soft limit, so a cgroup can > exceed the limit quite a bit before reclaim before page demotion reins > it in. I have to say that I dislike abusing soft limit reclaim for this. In the past we have learned that the existing implementation is unfixable and changing the existing semantic impossible due to backward compatibility. So I would really prefer the soft limit just find its rest rather than see new potential usecases. I haven't really looked into details of this patchset but from a cursory look it seems like you are actually introducing a NUMA aware limits into memcg that would control consumption from some nodes differently than other nodes. This would be rather alien concept to the existing memcg infrastructure IMO. It looks like it is fusing borders between memcg and cputset controllers. You also seem to be basing the interface on the very specific usecase. Can we expect that there will be many different tiers requiring their own balancing? -- Michal Hocko SUSE Labs