On Fri, Jun 28, 2024 at 09:57:37AM -0700, Christoph Lameter (Ampere) wrote:
On Fri, 28 Jun 2024, Catalin Marinas wrote:Linux-specific (e.g. madvise()), I agree, but arm64-specific definitely
On Wed, Jun 26, 2024 at 12:18:30PM -0700, Yang Shi wrote:Doing so would be requesting application code changes that are linux and
@@ -568,6 +596,12 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,The patch looks fine now and AFAICT there's no ABI change.
if (!vma)
goto lock_mmap;
+ if ((vm_flags & VM_READ) && (vma->vm_flags & VM_WRITE) &&
+ is_el0_atomic_instr(regs)) {
+ vm_flags = VM_WRITE;
+ mm_flags |= FAULT_FLAG_WRITE;
+ }
However, before deciding whether to merge this patch, I'd like to
understand why OpenJDK cannot use madvise(MADV_POPULATE_WRITE). This
would be the portable (Linux) solution that works better on
architectures without such atomic instructions (e.g. arm64 without LSE
atomics). So fixing user-space would be my preferred solution.
ARM64 specific from applications running on Linux.
not. I'd argue that expecting the atomic_add(0) to only trigger a single
write fault is arch specific. You can't do this on arm32 or arm64
pre-LSE (I haven't checked other architectures).
IIUC, OpenJDK added this feature about two years ago but the arm64
behaviour hasn't changed in the meantime. So it's not like we broke the
ABI and forcing user space to update.
This patch does feel a bit like working around a non-optimal user choice
in kernel space. Who knows, madvise() may even be quicker if you do a
single call for a larger VA vs touching each page.
A lot of these are proprietary.Are you aware of other (proprietary) software relying on such pattern to
fault pages in as writeable?