Re: [RFC][PATCH 0/5] VM_PINNED
From: Peter Zijlstra
Date: Tue May 27 2014 - 06:29:25 EST
On Tue, May 27, 2014 at 12:49:08AM +0400, Konstantin Khlebnikov wrote:
> On Tue, May 27, 2014 at 12:32 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > Pretty much, that's adequate for all users I'm aware of and mirrors the
> > mlock semantics.
>
> Ok, fine. Because get_user_pages is used sometimes for pinning pages
> from different mm.
Yeah, but that's fairly uncommon, and not something we do for very long
times afaik.
In fact I could only find:
drivers/iommu/amd_iommu_v2.c
fs/exec.c -- temporary use
kernel/events/uprobes.c -- temporary use
mm/ksm.c -- temporary use
mm/process_vm_access.c -- temporary use
With exception of the iommu one (it wasn't immediately obvious and I
didn't want to stare at the iommu muck too long), they're all temporary,
we drop the page almost immediately again after doing some short work.
The things I care about for VM_PINNED are long term pins, like the IB
stuff, which sets up its RDMA buffers at the start of a program and
basically leaves them in place for the entire duration of said program.
Such pins will disrupt CMA, compaction and pretty much anything that
relies on the page blocks stuff.
> Another suggestion. VM_RESERVED is stronger than VM_LOCKED and extends
> its functionality.
> Maybe it's easier to add VM_DONTMIGRATE and use it together with VM_LOCKED.
> This will make accounting easier. No?
I prefer the PINNED name because the not being able to migrate is only
one of the desired effects of it, not the primary effect. We're really
looking to keep physical pages in place and preserve mappings.
The -rt people for example really want to avoid faults (even minor
faults), and DONTMIGRATE would still allow unmapping.
Maybe always setting VM_PINNED and VM_LOCKED together is easier, I
hadn't considered that. The first thing that came to mind is that that
might make the fork() semantics difficult, but maybe it works out.
And while we're on the subject, my patch preserves PINNED over fork()
but maybe we don't actually need that either.
Attachment:
pgpqFudfEU43E.pgp
Description: PGP signature