From: Dave Hansen <dave.hansen@intel.com>
To: "Manwaring, Derek" <derekmn@amazon.com>
Cc: ackerleytng@google.com, agordeev@linux.ibm.com,
aou@eecs.berkeley.edu, borntraeger@linux.ibm.com, bp@alien8.de,
canellac@amazon.at, catalin.marinas@arm.com,
chenhuacai@kernel.org, corbet@lwn.net,
dave.hansen@linux.intel.com, david@redhat.com,
elena.reshetova@intel.com, gerald.schaefer@linux.ibm.com,
gor@linux.ibm.com, graf@amazon.com, hca@linux.ibm.com,
hpa@zytor.com, jgowans@amazon.com, jthoughton@google.com,
kalyazin@amazon.com, kernel@xen0n.name, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
loongarch@lists.linux.dev, luto@kernel.org,
mathieu.desnoyers@efficios.com, mhiramat@kernel.org,
mingo@redhat.com, mlipp@amazon.at, palmer@dabbelt.com,
paul.walmsley@sifive.com, pbonzini@redhat.com,
peterz@infradead.org, quic_eberman@quicinc.com,
rostedt@goodmis.org, roypat@amazon.co.uk, rppt@kernel.org,
seanjc@google.com, shuah@kernel.org, svens@linux.ibm.com,
tabba@google.com, tglx@linutronix.de, vannapurve@google.com,
will@kernel.org, x86@kernel.org, xmarcalx@amazon.com
Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd
Date: Fri, 1 Nov 2024 12:39:21 -0700 [thread overview]
Message-ID: <4a015283-28e2-4459-825a-1fd542b81110@intel.com> (raw)
In-Reply-To: <71e9b2c8-0cc4-4646-88f0-7780e108e610@amazon.com>
On 11/1/24 12:29, Manwaring, Derek wrote:
> As far as performance, are you talking about just the fracturing or
> something beyond that? The data Mike brought to LSFMMBPF 2023 showed the
> perf impact from direct map fragmentation for memfd_secret isn't "that
> bad" [1].
Just the fracturing.
Mike's data are interesting, but I still think we're pretty far away
from saying that the kernel doesn't need large mappings.
next prev parent reply other threads:[~2024-11-01 19:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 13:49 Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 1/6] arch: introduce set_direct_map_valid_noflush() Patrick Roy
2024-10-31 9:57 ` David Hildenbrand
2024-11-11 12:12 ` Vlastimil Babka
2024-11-12 14:48 ` Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 2/6] kvm: gmem: add flag to remove memory from kernel direct map Patrick Roy
2024-10-31 13:56 ` Mike Day
2024-10-30 13:49 ` [RFC PATCH v3 3/6] kvm: gmem: implement direct map manipulation routines Patrick Roy
2024-10-31 14:19 ` Mike Day
2024-10-30 13:49 ` [RFC PATCH v3 4/6] kvm: gmem: add trace point for direct map state changes Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 5/6] kvm: document KVM_GMEM_NO_DIRECT_MAP flag Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 6/6] kvm: selftests: run gmem tests with KVM_GMEM_NO_DIRECT_MAP set Patrick Roy
2024-10-31 9:50 ` [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd David Hildenbrand
2024-10-31 10:42 ` Patrick Roy
2024-11-01 0:10 ` Manwaring, Derek
2024-11-01 15:18 ` Sean Christopherson
2024-11-01 18:32 ` Kaplan, David
2024-11-01 16:06 ` Dave Hansen
2024-11-01 16:56 ` Manwaring, Derek
2024-11-01 17:20 ` Dave Hansen
2024-11-01 18:31 ` Manwaring, Derek
2024-11-01 18:43 ` Dave Hansen
2024-11-01 19:29 ` Manwaring, Derek
2024-11-01 19:39 ` Dave Hansen [this message]
2024-11-04 8:33 ` Reshetova, Elena
2024-11-06 17:04 ` Manwaring, Derek
2024-11-08 10:36 ` Reshetova, Elena
2024-11-13 3:31 ` Manwaring, Derek
2024-11-04 12:18 ` David Hildenbrand
2024-11-04 13:09 ` Patrick Roy
2024-11-04 21:30 ` David Hildenbrand
2024-11-12 14:40 ` Patrick Roy
2024-11-12 14:52 ` David Hildenbrand
2024-11-15 16:59 ` Patrick Roy
2024-11-15 17:10 ` David Hildenbrand
2024-11-15 17:23 ` Patrick Roy
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=4a015283-28e2-4459-825a-1fd542b81110@intel.com \
--to=dave.hansen@intel.com \
--cc=ackerleytng@google.com \
--cc=agordeev@linux.ibm.com \
--cc=aou@eecs.berkeley.edu \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=canellac@amazon.at \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=derekmn@amazon.com \
--cc=elena.reshetova@intel.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=graf@amazon.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=jthoughton@google.com \
--cc=kalyazin@amazon.com \
--cc=kernel@xen0n.name \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=luto@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mlipp@amazon.at \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=quic_eberman@quicinc.com \
--cc=rostedt@goodmis.org \
--cc=roypat@amazon.co.uk \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=svens@linux.ibm.com \
--cc=tabba@google.com \
--cc=tglx@linutronix.de \
--cc=vannapurve@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xmarcalx@amazon.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