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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04478C43334 for ; Wed, 15 Jun 2022 15:24:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F6E66B0071; Wed, 15 Jun 2022 11:24:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A6B06B0072; Wed, 15 Jun 2022 11:24:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56DD26B0074; Wed, 15 Jun 2022 11:24:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 482276B0071 for ; Wed, 15 Jun 2022 11:24:02 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0C1E93513D for ; Wed, 15 Jun 2022 15:24:02 +0000 (UTC) X-FDA: 79580840724.29.D8C3D32 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf10.hostedemail.com (Postfix) with ESMTP id 383B6C0079 for ; Wed, 15 Jun 2022 15:23:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655306639; x=1686842639; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=ykflRw68m1/+YtPghFKGX38ewwpPpqo6gmWZMbFFPxE=; b=DzcdD4qJw94jHXS9t+M6Tzb+q/DuMKXvtZQxI7Rz1bnoP6V+I+nDNa4I k6U+b/c7SfWl7nqvcWcHHEhEuRHRnZrNUjlUrWE3YZJiHhTja6BBN/69c 282jDdqMKrCxjNa9wU8M1MLpe47j/IUY6EsKM3cpDa3cQzowwQ6xVf31J FQY7ieX1wF6lcTRZ2G68vNENiYbhqjhb8kcxjiJdafLgsMftt0WI6gQje aw8gIXWmRb8jDnL9iAiMdiMd9Qdo1oYZeBd+VK8P+wCRrlxS00fdkxg48 x4yaGJbRBRkXIg5WWSIiDsL7QWua5Po3e9VKWQ2nQkl5gg55CAyHUjbSL g==; X-IronPort-AV: E=McAfee;i="6400,9594,10378"; a="276570314" X-IronPort-AV: E=Sophos;i="5.91,302,1647327600"; d="scan'208";a="276570314" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2022 08:23:57 -0700 X-IronPort-AV: E=Sophos;i="5.91,302,1647327600"; d="scan'208";a="712984367" Received: from lgankov-mobl1.amr.corp.intel.com (HELO schen9-mobl.amr.corp.intel.com) ([10.209.78.147]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2022 08:23:57 -0700 Message-ID: <34f985f63e6dbaa60bb9d1edb6022e83b98304e4.camel@linux.intel.com> Subject: Re: [RFC PATCH 0/3] Cgroup accounting of memory tier usage From: Tim Chen To: Michal Hocko Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Wei Xu , Huang Ying , Greg Thelen , Yang Shi , Davidlohr Bueso , Brice Goglin , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Feng Tang , Jagdish Gediya , Baolin Wang , David Rientjes , "Aneesh Kumar K . V" , Shakeel Butt Date: Wed, 15 Jun 2022 08:23:56 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655306641; a=rsa-sha256; cv=none; b=LWzxRJT1/Ur5G/iLssHy9F3kF15jLQ7afsxz5erLZ6YdPy3x04AIyNz4bMJI8cp2OnPqn1 Qn0OkQUSCIaH7U8+0s8qkxcTTyJ4JiObHhOMrgiQUoOqE8B8+se+eX33lQU3raxdGuvbTH vBtKNvZE9Wa1M4cJQvcVZmDV/vUC6e0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DzcdD4qJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf10.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=tim.c.chen@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655306641; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=c1Oap7jwvzZJ06GtsF5rzRsx+OaOWVIjH9VWx1egdJo=; b=di/71vi/p5cuXmYCXWnUYfHNga8fSBa4/OQB/YckcONA7rSBzn4roIX57yKbTRrmcPD83c ZcUc+DEcK146kKRG3gDc5+5hJdSGlb5ZvAjhgsy3828vdqMdXcDs7kGqyvAzRBJAIsbnt/ KchPfHdmQq1yFOLQ6UJ2VeRi2lEv5+g= X-Rspamd-Queue-Id: 383B6C0079 X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DzcdD4qJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf10.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=tim.c.chen@linux.intel.com X-Rspamd-Server: rspam06 X-Stat-Signature: no1r3atw7ogou56tyjrheot1f91d7673 X-HE-Tag: 1655306638-671886 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 Wed, 2022-06-15 at 13:11 +0200, Michal Hocko wrote: > On Tue 14-06-22 15:25:32, Tim Chen wrote: > > For controlling usage of a top tiered memory by a cgroup, accounting > > of top tier memory usage is needed. This patch set implements the > > following: > > > > Patch 1 introduces interface and simple implementation to retrieve > > cgroup tiered memory usage > > Patch 2 introduces more efficient accounting with top tier memory page counter > > Patch 3 provides a sysfs interface to repot the the top tiered memory > > usage. > > I guess you meant cgroupfs here, right? Yes. > > > The patchset works with Aneesh's v6 memory-tiering implementation [1]. > > It is a preparatory patch set before introducing features to > > control top tiered memory in cgroups. > > > > I'll like to first get feedback to see if > > (1) Controllng the topmost tiered memory is enough > > or > > (2) Multiple tiers at the top levels need to be grouped into "toptier" > > or > > (3) There are use cases not covered by (1) and (2). > > I would start by asking why do we need a dedicated interface in the > first place. Why the existing numa_stat is not a proper interface. Right > now we only report LRU per node stats. Is this insufficient? > What is userspace expect to do based on the reported data? Exporting the toptier information here is convenient for me for debugging purpose of seeing whether a cgroup's toptier usage is under control. Otherwise writing a script to parse numastat and the memtier heirachy will work too. Exporting toptier usage directly is optional and we don't have to do it. Tim