LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* copy_page_range() with VM_LOCKED
@ 2008-03-10 16:26 Will Newton
  2008-03-10 17:40 ` Hugh Dickins
  0 siblings, 1 reply; 3+ messages in thread
From: Will Newton @ 2008-03-10 16:26 UTC (permalink / raw)
  To: LKML

Hi all,

In order to optimize fork performance copy_page_range avoids copying
page tables under certain circumstances:

        if (!(vma->vm_flags &
(VM_HUGETLB|VM_NONLINEAR|VM_PFNMAP|VM_INSERTPAGE))) {
                if (!vma->anon_vma)
                        return 0;
        }

I have a VM_LOCKED vma that I would really, really like not to fault
on, but because copy_page_range does not copy the page tables of the
vma I do end up faulting in my VM_LOCKED vma. Now as far as I'm aware
mmap with MAP_LOCKED only promises the page will not be paged out, not
that the page will never fault but I would like to get that behaviour.

Would it be possible to add VM_LOCKED to the above conditional so
copy_page_range would always copy VM_LOCKED vma page tables or would
that be considered insane and broken?

Thanks,

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: copy_page_range() with VM_LOCKED
  2008-03-10 16:26 copy_page_range() with VM_LOCKED Will Newton
@ 2008-03-10 17:40 ` Hugh Dickins
  2008-03-10 18:53   ` Will Newton
  0 siblings, 1 reply; 3+ messages in thread
From: Hugh Dickins @ 2008-03-10 17:40 UTC (permalink / raw)
  To: Will Newton; +Cc: LKML

On Mon, 10 Mar 2008, Will Newton wrote:
> 
> In order to optimize fork performance copy_page_range avoids copying
> page tables under certain circumstances:
> 
>         if (!(vma->vm_flags &
> (VM_HUGETLB|VM_NONLINEAR|VM_PFNMAP|VM_INSERTPAGE))) {
>                 if (!vma->anon_vma)
>                         return 0;
>         }
> 
> I have a VM_LOCKED vma that I would really, really like not to fault
> on, but because copy_page_range does not copy the page tables of the
> vma I do end up faulting in my VM_LOCKED vma.

Faulting on the child's (non-)copy of the parent's VM_LOCKED vma.
Yes, but did you realize that VM_LOCKED is cleared from the child's
vma (the "vma" in that code sample above happens to be the parent's)?
Though an area is locked in the parent, that's not carried over to the
child.

> Now as far as I'm aware
> mmap with MAP_LOCKED only promises the page will not be paged out, not
> that the page will never fault but I would like to get that behaviour.
> 
> Would it be possible to add VM_LOCKED to the above conditional so
> copy_page_range would always copy VM_LOCKED vma page tables or would
> that be considered insane and broken?

It would be possible, but I don't think it would be justified - for
everybody who wants your behaviour, there'll be others who want the
current behaviour (and that condition reflects those cases on which
correctness demands we do the copy).

If you really want that, I think you'll have to patch your own kernel.

But much much better, mlock that area in your child after the fork,
since it isn't actually locked at present: that mlock will bring in
the pages - not quite as efficiently as copy_page_range would have done,
but as or more efficiently than the original mlock in the parent.

Hugh

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: copy_page_range() with VM_LOCKED
  2008-03-10 17:40 ` Hugh Dickins
@ 2008-03-10 18:53   ` Will Newton
  0 siblings, 0 replies; 3+ messages in thread
From: Will Newton @ 2008-03-10 18:53 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: LKML

On Mon, Mar 10, 2008 at 5:40 PM, Hugh Dickins <hugh@veritas.com> wrote:

>  > mmap with MAP_LOCKED only promises the page will not be paged out, not
>  > that the page will never fault but I would like to get that behaviour.
>  >
>  > Would it be possible to add VM_LOCKED to the above conditional so
>  > copy_page_range would always copy VM_LOCKED vma page tables or would
>  > that be considered insane and broken?
>
>  It would be possible, but I don't think it would be justified - for
>  everybody who wants your behaviour, there'll be others who want the
>  current behaviour (and that condition reflects those cases on which
>  correctness demands we do the copy).
>
>  If you really want that, I think you'll have to patch your own kernel.
>
>  But much much better, mlock that area in your child after the fork,
>  since it isn't actually locked at present: that mlock will bring in
>  the pages - not quite as efficiently as copy_page_range would have done,
>  but as or more efficiently than the original mlock in the parent.

The reason I want to do this is to work around a silicon bug so I'd
rather keep the whole workaround in the kernel rather than hacking the
C library etc. I wasn't aware that the VM_LOCKED flag would be lost in
the child, it looks like I'll have to come up with a more creative
solution...

Thanks for taking the time to explain how this stuff fits together,

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-03-10 18:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-10 16:26 copy_page_range() with VM_LOCKED Will Newton
2008-03-10 17:40 ` Hugh Dickins
2008-03-10 18:53   ` Will Newton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).