From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>, linux-mm <linux-mm@kvack.org>
Subject: Re: THP race?
Date: Fri, 26 Feb 2016 13:37:42 +0300 [thread overview]
Message-ID: <20160226103742.GC22450@node.shutemov.name> (raw)
In-Reply-To: <CAA9_cmcoVs=bM5Q+=tGEBFoA-OG9A50NiM2vz+mXBkCtu0jm-A@mail.gmail.com>
On Thu, Feb 25, 2016 at 10:45:05AM -0800, Dan Williams wrote:
> On Tue, Feb 23, 2016 at 11:28 AM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> > On Tue, Feb 23, 2016 at 09:38:32PM +0300, Kirill A. Shutemov wrote:
> >> pmd_trans_unstable(pmd), otherwise looks good:
> >
> > Yes sorry.
> >
> >> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> >
> > Thanks for the quick ack, I just noticed or I would have added it to
> > the resubmit, but it can be still added to -mm.
> >
> >> BTW, I guess DAX would need to introduce the same infrastructure for
> >> pmd_devmap(). Dan?
> >
> > There is a i_mmap_lock_write in the truncate path that saves the day
> > for the pmd zapping in the truncate() case without mmap_sem (the only
> > case anon THP doesn't need to care about as truncate isn't possible in
> > the anon case), but not in the MADV_DONTNEED madvise case that runs
> > only with the mmap_sem for reading.
> >
> > The only objective of this "infrastructure" is to add no pmd_lock()ing
> > overhead to the page fault, if the mapping is already established but
> > not huge, and we've just to walk through the pmd to reach the
> > pte. All because MADV_DONTNEED is running with the mmap_sem for
> > reading unlike munmap and other slower syscalls that are forced to
> > mangle the vmas and have to take the mmap_sem for writing regardless.
> >
> > The question for DAX is if it should do a pmd_devmap check inside
> > pmd_none_or_trans_huge_or_clear_bad() after pmd_trans_huge() and get
> > away with a one liner, or add its own infrastructure with
> > pmd_devmap_unstable(). In the pmd_devmap case the problem isn't just
> > in __handle_mm_fault. If it could share the same infrastructure it'd
> > be ideal.
> >
>
> Yes, I see no reason why we can't/shoudn't move the pmd_devmap() check
> inside pmd_none_or_trans_huge_or_clear_bad().
Are you going take care about this?
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-02-26 10:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 15:49 THP race? Kirill A. Shutemov
2016-02-23 18:06 ` Andrea Arcangeli
2016-02-23 18:18 ` [PATCH 1/1] mm: thp: fix SMP race condition between THP page fault kbuild test robot
2016-02-23 18:21 ` kbuild test robot
2016-02-23 18:27 ` kbuild test robot
2016-02-23 18:38 ` THP race? Kirill A. Shutemov
2016-02-23 19:28 ` Andrea Arcangeli
2016-02-25 18:45 ` Dan Williams
2016-02-26 10:37 ` Kirill A. Shutemov [this message]
2016-02-26 14:46 ` Dan Williams
2016-02-23 18:49 ` [PATCH 0/1] " Andrea Arcangeli
2016-02-23 18:49 ` [PATCH 1/1] mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED Andrea Arcangeli
2016-02-23 21:18 ` Andrew Morton
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=20160226103742.GC22450@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=aarcange@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=linux-mm@kvack.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.