LWN: Comments on "Memory-management optimization with DAMON"

Memory-management optimization with DAMON

gerlash — Wed, 07 Sep 2022 09:46:14 +0000

Do you have some pointers to an alternative?

Memory-management optimization with DAMON

scientes — Fri, 23 Jul 2021 18:56:04 +0000

> To a great extent, memory management is based on making predictions: which pages of memory will a given process need in the near future?

That is what *caching* is about. We have random access memory for a reason, and even a MMU and the overhead it brings (easily turning a single access into 5 accesses) is unnecessary (and does not mean insecurity, although that is the general assumption). You've locked yourself into an overcommit world, and then are trying to remove all the dung that comes with it, but I really think that is the wrong approach.

MMUs were designed the way they are because it was a virtual machine approach to DOS (and then history repeats itsself with what we now call virtual machines), but it isn't the most efficient method of adding multi-process memory access security to RAM, with the power-hungry TLBs.

Memory-management optimization with DAMON

sjpark — Mon, 02 Mar 2020 11:52:10 +0000

For the test, I ran the application in a seperated cgroup. Thus, the speedup was not came from such sacrifices of other processes. You can show the detailed setup of the tests in the related paper: https://dl.acm.org/doi/10.1145/3366626.3368125

Memory-management optimization with DAMON

Karellen — Thu, 27 Feb 2020 11:31:35 +0000

we identified frequently accessed memory regions in each workload based on the DAMON results and protected them with mlock() system calls. The optimized versions consistently show speedup (2.55x in best case, 1.65x in average) under memory pressure.

If feel like "under memory pressure" should be emphasised here. Yes, if you're low on memory and the system is needing to swap, then preventing some regions of memory from being swapped could certainly improve the performance... of that particular application.

However, if you're low on memory and the system is needing to swap, then preventing some regions of memory from being swapped is probably going to have an adverse effect on all the other applications on the system.

That kind of speedup certainly justifies spending some time looking at a process's memory patterns. It would be even nicer, though, if the kernel could do that work itself — that is what a memory-management subsystem is supposed to be for, after all.

I feel like the memory management subsystem should be for making the system as fair as possible?

Memory-management optimization with DAMON

josh — Fri, 21 Feb 2020 07:28:59 +0000

https://quoteinvestigator.com/2013/10/20/no-predict/

Memory-management optimization with DAMON

gus3 — Fri, 21 Feb 2020 02:45:58 +0000

You're conflating "distant" future with "immediate" future.

I can predict that smacking your thumb with a hammer will cause pain. That is "immediate."

But I cannot predict that you *will* smack your thumb with a hammer, anytime today. That is "future."

The immediate future is usually knowable. The distant future, not so much.

Memory-management optimization with DAMON

xanni — Fri, 21 Feb 2020 01:08:50 +0000

thatsthejoke.gif

But also, when testing scientific hypotheses it's common to make predictions about current or past events in order to determine the accuracy of the predictions. This is how models are created.

Memory-management optimization with DAMON

nickodell — Fri, 21 Feb 2020 00:16:11 +0000

>Unfortunately, it turns out that predictions are hard, especially when they are about future events.

Aren't all predictions about future events?

Memory-management optimization with DAMON

sjpark — Thu, 20 Feb 2020 15:57:35 +0000

Appreciate this great introduction of my patchsets, Jon!

I also made several web pages showing DAMON outputs in more intuitive (visualized) way: https://lore.kernel.org/linux-mm/20200220081710.15211-1-s...
You can show how the data access pattern monitored by DAMON seems like there. Nonetheless, the pages are showing only visualized data access patterns and related analysis results. More reports including performance test results will be also available soon at https://damonitor.github.io/reports/latest/. Stay tuned!

Also, I would like to give my answer to the last question: "given that the kernel can be made to tune itself for better memory-management results, why isn't this capability a part of the memory-management subsystem itself?"

Actually, DAMON provides two interfaces. The interfaces using debugfs and the tracepoints are for privileged userspace programs, profilers, and people. Beside of the interface, DAMON also provides a programmable interface for kernel code. Using this programmable interface, the memory-management subsystem can use DAMON. Indeed, making the system 'Just Work' in optimal way using DAMON is the ultimate goal of this project.

That said, I believe the debugfs interfaces could still be an useful and easy-to-control knob for environments having unique characteristics. Of course, third party kernel modules using the programmable interface for complex schemes which cannot described with the simple format ('min-size max-size min-acc max-acc min-age max-age action') for specific environments are also imaginable.