From: Luis Chamberlain <mcgrof@kernel.org>
To: Michal Hocko <mhocko@suse.com>, Dan Williams <dan.j.williams@intel.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>, Yu Zhao <yuzhao@google.com>,
John Hubbard <jhubbard@nvidia.com>,
Daniel Gomez <da.gomez@samsung.com>,
linux-mm <linux-mm@kvack.org>,
lsf-pc@lists.linux-foundation.org
Subject: [LSFMM] automating measuring memory fragmentation
Date: Wed, 15 May 2024 12:34:53 -0700 [thread overview]
Message-ID: <ZkUOXQvVjXP1T6Nk@bombadil.infradead.org> (raw)
RFC to see if we have a breakout session today at LSFMM.
After the TAO talk today it occurred to me that it might make sense
to review how we're measuring memory fragmentation today. We're looking
to add automation support into kdevops for this to help compare and
contrast memory fragmentation behaviour with one kernel against another.
A while ago, while mTHP was being evaluated I asked genearlly how we
could measure fragmentation with a simple one value, and John Hubbard
had one recommendation [0], working that proved we could simplify things
[1] but we also could just use the existing fragmentation index and only
consider the values where this is concerned for fragmentation and not
lack of memory. It begs the question of how folks are measuring memory
fragmentation today in production, and if they have any desirable
changes. The first approach being considered is to reproduce the
workloads Mel Gorman had written and used for mmtests and leverage those
on kdevops, perhaps modernize them, but before we do so it seems
reviewing how we measure fragmentation today might be useful to others
too.
As for mmtests integration into kdevops, first order of business are
just a few distro-friendly updates [2], for the next steps after that
though it would be great to review the above.
[0] https://lore.kernel.org/all/5ac6a387-0ca7-45ca-bebc-c3bdd48452cb@nvidia.com/T/#u
[1] https://lkml.kernel.org/r/20240314005710.2964798-1-mcgrof@kernel.org
[2] https://lore.kernel.org/kdevops/20240319044621.2682968-1-mcgrof@kernel.org/
Luis
next reply other threads:[~2024-05-15 19:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-15 19:34 Luis Chamberlain [this message]
2024-05-16 5:15 ` [LSFMM] automating measuring memory fragmentation Yu Zhao
2024-05-16 6:23 ` Luis Chamberlain
2024-05-16 20:05 ` Yu Zhao
2024-05-16 21:32 ` Karim Manaouil
2024-05-16 21:36 ` Yu Zhao
2024-05-20 14:34 ` Vlastimil Babka (SUSE)
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=ZkUOXQvVjXP1T6Nk@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dan.j.williams@intel.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.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 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).