All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: lsf-pc@lists.linux-foundation.org, damon@lists.linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] DAMON Updates and Plans: Automation of DAMON tuning, tiering, and VM guest scaling
Date: Sun, 12 May 2024 12:44:01 -0700	[thread overview]
Message-ID: <20240512194401.79396-1-sj@kernel.org> (raw)
In-Reply-To: <20240129204749.68549-1-sj@kernel.org>

On Mon, 29 Jan 2024 12:47:49 -0800 SeongJae Park <sj@kernel.org> wrote:

> Hi all,
> 
> 
> Thanks to the discussions and feedback that we received last year from the
> LSF/MM/BPF 2023's DAMON updates and future plans session[1], DAMON made many
> advances and yet more future plans.  I'd like to again share/discuss the
> followup changes and status we made so far after the last year's session, and
> the future development plans on LSF/MM/BPF 2024.
> 
> A few topics would be shared, including below.
>
[...]
>
> Access/Contiguity-aware Memory Auto-scaling
> -------------------------------------------
> 
> This is a new idea which was not discussed in last year's LSF/MM/BPF.  The main
> purpose is to implement an access-aware, efficient, reliable, and simple to use
> memory over-subscribed VM guest kernels.  Specifically, it will steal guest
> memory based on access patterns in a contiguity-aware manner and report those
> to the host as free to use.  The PSI-based stealing aggressiveness auto-tuning
> may be used.  It will also apply a 'struct page' overhead reduction mechanism
> to the stolen memory.  We're currently thinking about memory hotplugging and
> vmemmap remapping as candidate mechanisms.  For simple usage, the interface
> will be similar to that of virtio-balloon, which is widely adopted.  The first
> version of the more detailed idea[7] has been shared before.
> 
> Because it is still at a pure idea level, not much progress until LSF/MM/BPF is
> expected.  This item would be primarily for the future plans part.  That said,
> at least a second version of the design will be shared before.  Also hopefully
> early proof-of-concepts level implementation or some test results will be
> shared.  Since this is expected to be more for future plans than status update,
> I hope to have more discussions for getting design level concerns and possible
> collaboration chances.

I just posted the RFC IDEA v2 of this with pseudo-code level implementation
example: https://lore.kernel.org/all/20240512193657.79298-1-sj@kernel.org/

Hopefully it will help the idea success or fail faster :)


Thanks,
SJ

[...]

      parent reply	other threads:[~2024-05-12 19:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 20:47 [LSF/MM/BPF TOPIC] DAMON Updates and Plans: Automation of DAMON tuning, tiering, and VM guest scaling SeongJae Park
2024-05-10 21:21 ` SeongJae Park
2024-05-10 21:32   ` SeongJae Park
2024-05-12 19:44 ` SeongJae Park [this message]

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=20240512194401.79396-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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.