All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeelb@google.com>
To: SeongJae Park <sj38.park@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	SeongJae Park <sjpark@amazon.de>,
	Jonathan.Cameron@huawei.com, amit@kernel.org,
	Jonathan Corbet <corbet@lwn.net>,
	David Hildenbrand <david@redhat.com>,
	dwmw@amazon.com, foersleo@amazon.de,
	Greg Thelen <gthelen@google.com>,
	jgowans@amazon.com, mheyne@amazon.de,
	David Rientjes <rientjes@google.com>,
	sieberf@amazon.com, Vlastimil Babka <vbabka@suse.cz>,
	linux-damon@amazon.com, Linux MM <linux-mm@kvack.org>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Wei Xu <weixugc@google.com>, Paul Turner <pjt@google.com>,
	Yu Zhao <yuzhao@google.com>, Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH v34 00/13] Introduce Data Access MONitor (DAMON)
Date: Tue, 27 Jul 2021 14:30:38 -0700	[thread overview]
Message-ID: <CALvZod53+KD_F+3z3ztdx6ELFWt+jAXY6Vq-S49bq6-Y2=Cneg@mail.gmail.com> (raw)
In-Reply-To: <20210716081449.22187-1-sj38.park@gmail.com>

(reduced CC list)

Hi all,

I have been asked to comment if Google is interested in using this
feature, its general usefulness and if it is sufficiently general and
non-duplicative. I will try to answer these but first I will explain
the use-cases we are particularly interested in and for which we want
a general access monitoring mechanism.

At the moment Google is particularly interested in four use-cases:

1) Working set estimation: This is used for cluster level scheduling
and controlling the knobs of memory overcommit.

2) Proactive reclaim

3) Balancing between memory tiers: Moving hot pages to fast tiers and
cold pages to slow tiers

4) Hugepage optimization: Hot memory backed by hugepages

In addition, these uses are not happening in isolation. We want a
combination of these running concurrently on a system. So, it is clear
that the first version or step of DAMON which only targets virtual
address space monitoring is not sufficient for these use-cases.

I think the more important question is if DAMON can be extended to
system level monitoring to fulfill these use-cases. Address space
monitoring is a core concept in DAMON and it has implemented address
space based optimizations (i.e. dividing address space into regions,
assuming locality within regions, random sampling within regions
instead of looking at each page and dynamically adjusting regions).
There is a followup proposal on monitoring physical address space in
DAMON. However for systems running multiple workloads, the address
space optimizations core to DAMON would be ineffective.

There are discussions/brainstorming on supporting abstract address
space based on LRUs which is somewhat similar to Multigen LRU [1]
proposal but not well articulated yet. BTW Multigen LRU [1] is another
similar proposal but targets one specific use-case i.e. memory reclaim
(proactive reclaim). Anyways I think we need more brainstorming for a
generalized solution of system level access monitoring.

Regarding merging DAMON, I personally think there are users who might
be interested in only their virtual address space and DAMON is
providing a solution for such users. SeongJae can provide more details
or knowledge if any big user other than Amazon is interested in the
feature. DAMON does not expose stable APIs at the moment, so these can
be changed later if needed. I think it is ok to merge DAMON for some
exposure. However I do want to make this clear that the solution space
is not complete. The solution of system level monitoring is still
needed which can be a future extension to DAMON or more generalized
Multigen LRU.

thanks,
Shakeel

[1] https://lore.kernel.org/lkml/20210520065355.2736558-1-yuzhao@google.com/

  parent reply	other threads:[~2021-07-27 21:30 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16  8:14 [PATCH v34 00/13] Introduce Data Access MONitor (DAMON) SeongJae Park
2021-07-16  8:14 ` [PATCH v34 01/13] mm: " SeongJae Park
2021-07-16  8:14 ` [PATCH v34 02/13] mm/damon/core: Implement region-based sampling SeongJae Park
2021-07-16  8:14 ` [PATCH v34 03/13] mm/damon: Adaptively adjust regions SeongJae Park
2021-07-16  8:14 ` [PATCH v34 04/13] mm/idle_page_tracking: Make PG_idle reusable SeongJae Park
2021-07-16  8:14 ` [PATCH v34 05/13] mm/damon: Implement primitives for the virtual memory address spaces SeongJae Park
2021-08-26 14:09   ` David Hildenbrand
2021-08-26 17:29     ` SeongJae Park
2021-08-26 21:42       ` David Hildenbrand
2021-08-27 11:06         ` SeongJae Park
2021-07-16  8:14 ` [PATCH v34 06/13] mm/damon: Add a tracepoint SeongJae Park
2021-07-16  8:14 ` [PATCH v34 07/13] mm/damon: Implement a debugfs-based user space interface SeongJae Park
2021-08-06  0:43   ` Andrew Morton
2021-08-06 11:46     ` SeongJae Park
2021-08-06  0:43   ` Andrew Morton
2021-08-06 11:47     ` SeongJae Park
2021-07-16  8:14 ` [PATCH v34 08/13] mm/damon/dbgfs: Export kdamond pid to the user space SeongJae Park
2021-07-16  8:14 ` [PATCH v34 09/13] mm/damon/dbgfs: Support multiple contexts SeongJae Park
2021-07-16  8:14 ` [PATCH v34 10/13] Documentation: Add documents for DAMON SeongJae Park
2021-07-16  8:14 ` [PATCH v34 11/13] mm/damon: Add kunit tests SeongJae Park
2021-07-16  8:14 ` [PATCH v34 12/13] mm/damon: Add user space selftests SeongJae Park
2021-07-16  8:14 ` [PATCH v34 13/13] MAINTAINERS: Update for DAMON SeongJae Park
2021-07-27 21:30 ` Shakeel Butt [this message]
2021-07-27 21:30   ` [PATCH v34 00/13] Introduce Data Access MONitor (DAMON) Shakeel Butt
2021-07-28  8:36   ` SeongJae Park
2021-08-02  8:24     ` SeongJae Park
2021-08-04  7:41       ` SeongJae Park
2021-08-06  0:03     ` Andrew Morton
2021-08-06 11:48       ` SeongJae Park
2021-08-09 14:07         ` SeongJae Park
2021-08-06  0:43 ` Andrew Morton
2021-08-06 11:48   ` SeongJae Park
2021-08-07 18:28     ` Andrew Morton
2021-07-23  7:02 Dongjoo Seo
2021-07-23  7:08 ` Greg KH
2021-07-23  7:16   ` Dongjoo Seo
2021-07-23  7:30     ` Greg KH
2021-07-23  7:51       ` Dongjoo Seo
2021-07-23  8:30 ` SeongJae Park
2021-07-23  8:40   ` SeongJae Park
2021-07-26 13:32   ` SeongJae Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALvZod53+KD_F+3z3ztdx6ELFWt+jAXY6Vq-S49bq6-Y2=Cneg@mail.gmail.com' \
    --to=shakeelb@google.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=amit@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=dwmw@amazon.com \
    --cc=foersleo@amazon.de \
    --cc=gthelen@google.com \
    --cc=jgowans@amazon.com \
    --cc=linux-damon@amazon.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mheyne@amazon.de \
    --cc=pjt@google.com \
    --cc=rientjes@google.com \
    --cc=sieberf@amazon.com \
    --cc=sj38.park@gmail.com \
    --cc=sjpark@amazon.de \
    --cc=vbabka@suse.cz \
    --cc=weixugc@google.com \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.