From: Piyush Sachdeva <piyushs@linux.ibm.com>
To: sjpark@amazon.de, damon@lists.linux.dev
Cc: linux-mm@kvack.org, aneesh.kumar@linux.ibm.com
Subject: DAMON testing and benchmarking
Date: Tue, 13 Jun 2023 12:18:48 +0530 [thread overview]
Message-ID: <e6e8c252-f7b4-e71f-0315-f6cc774354d2@linux.ibm.com> (raw)
Dear Mr. SeongJae Park,
I hope this email finds you well.
For the last few months, I have been looking at DAMON from an end-users
perspective and a developer's PoV. Most recently, I was focusing on
`lru_sort.c` module that uses the `lru_prio` and `lru_deprio` operations
which result in a more precise reclaim. In my understanding, enabling
the "lru_sort.c" module would make intelligent decisions based on the
access frequency of the pages and end up preventing hot page
swaps. Hence, when integrated with an LRU algorithm, it should improve
it.
If you could share any test/benchmark that you might have run to verify
the above assumption? I did find the result numbers you posted (link
below), but that doesn't mention the "plrus-*" scheme numbers. It also
doesn't have numbers for running the `pageout` operation on the entire
physical address space (paddr) i.e. the `pprcl` scheme. So, if you can
link those too, it would be amazing.
Can you also share any real-world (memory-management specific) workload
results that you would have used with DAMON in your experiments? Like
either MongoDB or memcached over Parsec3.0 (including splash2x) - which,
in my understanding, is less memory intensive and more architecture
inclined.
I also had a question regarding schemes - A scheme is highly tweakable,
and it's what the efficiency of DAMON rests upon. The more precise the
scheme, the more efficient DAMON will be. Hence, I'd be thankful if you
can help me derive a config that would provide the best results.
Hope to hear from you soon.
Test results: https://damonitor.github.io/test/result/perf/latest/html/
--
Regards,
Piyush Sachdeva
next reply other threads:[~2023-06-13 6:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 6:48 Piyush Sachdeva [this message]
2023-06-14 17:27 ` DAMON testing and benchmarking SeongJae Park
2023-06-16 6:52 ` Piyush Sachdeva
2024-01-07 21:06 ` 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=e6e8c252-f7b4-e71f-0315-f6cc774354d2@linux.ibm.com \
--to=piyushs@linux.ibm.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=damon@lists.linux.dev \
--cc=linux-mm@kvack.org \
--cc=sjpark@amazon.de \
/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).