qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] overcommit: introduce mem-lock-onfault


From: Daniil Tatianin
Subject: Re: [PATCH 0/2] overcommit: introduce mem-lock-onfault
Date: Tue, 10 Dec 2024 20:23:27 +0300
User-agent: Mozilla Thunderbird


On 12/10/24 8:20 PM, Peter Xu wrote:
On Tue, Dec 10, 2024 at 08:01:08PM +0300, Daniil Tatianin wrote:
I mentioned my use case in the cover letter. Basically we want to protect
QEMU's pages from being migrated and compacted by kcompactd, which it
accomplishes by modifying live page tables and spamming the process with TLB
invalidate IPIs while it does that, which kills guest performance for the
duration of the compaction operation.
Ah right, I read it initially but just now when I scanned the cover letter
I missed that.  My fault.

No worries!

Memory locking allows to protect a process from kcompactd page compaction
and more importantly, migration (that is taking a PTE and replacing it with
one, which is closer in memory to reduce fragmentation). (As long as
/proc/sys/vm/compact_unevictable_allowed is 0)

For this use case we don't mind page faults as they take more or less
constant time, which we can also avoid if we wanted by preallocating guest
memory. We do, however, want PTEs to be untouched by kcompactd, which
MCL_ONFAULT accomplishes just fine without the extra memory overhead that
comes from various anonymous mappings getting write-faulted with the
currently available mem-lock=on option.

In our case we use KVM of course, TCG was just an experiment where I noticed
anonymous memory
jump way too much.

I don't think it's feasible in our case to look for the origin of every
anonymous mapping that grew compared to the no mem-lock case (which there's
about ~30 with default Q35 + KVM, without any extra devices), and try to
optimize it to map anonymous memory less eagerly.
Would it be better then to use mem-lock=on|off|onfault?  So turns it into a
string to avoid the "exclusiveness" needed (meanwhile having two separate
knobs for relevant things looks odd too).

How did I not think of that.. Sounds much better IMO.

Thank you!

Thanks,




reply via email to

[Prev in Thread] Current Thread [Next in Thread]