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
[...]
prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).