public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Shi <alex.shi@intel.com>
To: Andrea Arcangeli <aarcange@redhat.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, 03 May 2012 08:56:57 +0800	[thread overview]
Message-ID: <4FA1D7D9.1050402@intel.com> (raw)
In-Reply-To: <20120502175508.GC2410@redhat.com>


> 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.

> 
>> Oh, yes. Since is_vma_temporay_stack is just used in rmap.c and huge_memory.c
>> . is it better to move it to huge_mm.h?
> 
> I guess it was cleaner on rmap.h as this is not related to THP, but
> clearly it works better in huge_mm.h (and rmap.h->mm.h->huge_mm.h is
> included automatically) so the patch looks fine to me.


Thanks for point out.

  reply	other threads:[~2012-05-03  0:58 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 [this message]
2012-05-03 11:25         ` Andrea Arcangeli
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=4FA1D7D9.1050402@intel.com \
    --to=alex.shi@intel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox