From: Andrea Arcangeli <aarcange@redhat.com>
To: Alex Shi <alex.shi@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
riel@redhat.com, mgorman@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] THP: need is_vma_temporary_stack() when reference transparent_hugepage_enabled
Date: Thu, 3 May 2012 13:25:30 +0200 [thread overview]
Message-ID: <20120503112530.GE2410@redhat.com> (raw)
In-Reply-To: <4FA1D7D9.1050402@intel.com>
Hi,
On Thu, May 03, 2012 at 08:56:57AM +0800, Alex Shi wrote:
>
> > My preference would still be to remove the is_vma_temporary_stack and
> > use two vmas during mremap of execve, that would remove the "vma"
> > parameter from transparent_hugepage_enabled() but others prefers to
> > skip a vma allocation in execve and stick to is_vma_temporary_stack,
> > which is fair enough argument.
>
>
> Actually, current transparent_hugepage_enabled just means the vma is in
> THP enable ENV, the vma is just possibly has some large page, no grantee
> really has. But in lots situations, user wants to know if a vma or a
> part of memory really include a large page. not the possibility.
>
> So, it will be great to see a real large page checking function appearing.
Well, to know if a VMA (or a memory range) really includes a THP, it'd
require to hold the page_table_lock and a loop on all pmds in the
range, but by the time you relase the lock things may have already
changed as split_huge_page can run at any time, madvise(MADV_DONTNEED)
too if you only hold the mmap_sem in read mode and the THP page
fault. In fact while holding the mmap_sem in read mode (the usual read
lock you need to take to lookup and stabilize the vma) a THP can be
freed and reallocated under it, and that's what pmd_trans_unstable is
about.
next prev parent reply other threads:[~2012-05-03 11:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-28 6:33 [PATCH] THP: need is_vma_temporary_stack() when reference transparent_hugepage_enabled Alex Shi
2012-04-30 23:05 ` Andrew Morton
2012-05-02 3:17 ` Alex Shi
2012-05-02 3:31 ` Alex Shi
2012-05-02 17:55 ` Andrea Arcangeli
2012-05-03 0:56 ` Alex Shi
2012-05-03 11:25 ` Andrea Arcangeli [this message]
2012-05-04 7:26 ` Alex Shi
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=20120503112530.GE2410@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.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 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.