All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andi Kleen <andi@firstfloor.org>,
	Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Larry Woodman <lwoodman@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 2/8] hugetlb, rmap: add reverse mapping for hugepage
Date: Wed, 2 Jun 2010 11:16:17 -0700	[thread overview]
Message-ID: <20100602111617.0c292178.akpm@linux-foundation.org> (raw)
In-Reply-To: <1275006562-18946-3-git-send-email-n-horiguchi@ah.jp.nec.com>

On Fri, 28 May 2010 09:29:16 +0900
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote:

> +#ifdef CONFIG_HUGETLBFS
> +/*
> + * The following three functions are for anonymous (private mapped) hugepages.
> + * Unlike common anonymous pages, anonymous hugepages have no accounting code
> + * and no lru code, because we handle hugepages differently from common pages.
> + */
> +static void __hugepage_set_anon_rmap(struct page *page,
> +	struct vm_area_struct *vma, unsigned long address, int exclusive)
> +{
> +	struct anon_vma *anon_vma = vma->anon_vma;
> +	BUG_ON(!anon_vma);
> +	if (!exclusive) {
> +		struct anon_vma_chain *avc;
> +		avc = list_entry(vma->anon_vma_chain.prev,
> +				 struct anon_vma_chain, same_vma);
> +		anon_vma = avc->anon_vma;
> +	}
> +	anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
> +	page->mapping = (struct address_space *) anon_vma;
> +	page->index = linear_page_index(vma, address);
> +}
> +
> +void hugepage_add_anon_rmap(struct page *page,
> +			    struct vm_area_struct *vma, unsigned long address)
> +{
> +	struct anon_vma *anon_vma = vma->anon_vma;
> +	int first;
> +	BUG_ON(!anon_vma);
> +	BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> +	first = atomic_inc_and_test(&page->_mapcount);
> +	if (first)
> +		__hugepage_set_anon_rmap(page, vma, address, 0);
> +}
> +
> +void hugepage_add_new_anon_rmap(struct page *page,
> +			struct vm_area_struct *vma, unsigned long address)
> +{
> +	BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> +	atomic_set(&page->_mapcount, 0);
> +	__hugepage_set_anon_rmap(page, vma, address, 1);
> +}
> +#endif /* CONFIG_HUGETLBFS */

This code still make sense if CONFIG_HUGETLBFS=n, I think?  Should it
instead depend on CONFIG_HUGETLB_PAGE?

I have a feeling that we make that confusion relatively often.  Perhaps
CONFIG_HUGETLB_PAGE=y && CONFIG_HUGETLBFS=n makes no sense and we
should unify them...  

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andi Kleen <andi@firstfloor.org>,
	Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Larry Woodman <lwoodman@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 2/8] hugetlb, rmap: add reverse mapping for hugepage
Date: Wed, 2 Jun 2010 11:16:17 -0700	[thread overview]
Message-ID: <20100602111617.0c292178.akpm@linux-foundation.org> (raw)
In-Reply-To: <1275006562-18946-3-git-send-email-n-horiguchi@ah.jp.nec.com>

On Fri, 28 May 2010 09:29:16 +0900
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote:

> +#ifdef CONFIG_HUGETLBFS
> +/*
> + * The following three functions are for anonymous (private mapped) hugepages.
> + * Unlike common anonymous pages, anonymous hugepages have no accounting code
> + * and no lru code, because we handle hugepages differently from common pages.
> + */
> +static void __hugepage_set_anon_rmap(struct page *page,
> +	struct vm_area_struct *vma, unsigned long address, int exclusive)
> +{
> +	struct anon_vma *anon_vma = vma->anon_vma;
> +	BUG_ON(!anon_vma);
> +	if (!exclusive) {
> +		struct anon_vma_chain *avc;
> +		avc = list_entry(vma->anon_vma_chain.prev,
> +				 struct anon_vma_chain, same_vma);
> +		anon_vma = avc->anon_vma;
> +	}
> +	anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
> +	page->mapping = (struct address_space *) anon_vma;
> +	page->index = linear_page_index(vma, address);
> +}
> +
> +void hugepage_add_anon_rmap(struct page *page,
> +			    struct vm_area_struct *vma, unsigned long address)
> +{
> +	struct anon_vma *anon_vma = vma->anon_vma;
> +	int first;
> +	BUG_ON(!anon_vma);
> +	BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> +	first = atomic_inc_and_test(&page->_mapcount);
> +	if (first)
> +		__hugepage_set_anon_rmap(page, vma, address, 0);
> +}
> +
> +void hugepage_add_new_anon_rmap(struct page *page,
> +			struct vm_area_struct *vma, unsigned long address)
> +{
> +	BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> +	atomic_set(&page->_mapcount, 0);
> +	__hugepage_set_anon_rmap(page, vma, address, 1);
> +}
> +#endif /* CONFIG_HUGETLBFS */

This code still make sense if CONFIG_HUGETLBFS=n, I think?  Should it
instead depend on CONFIG_HUGETLB_PAGE?

I have a feeling that we make that confusion relatively often.  Perhaps
CONFIG_HUGETLB_PAGE=y && CONFIG_HUGETLBFS=n makes no sense and we
should unify them...  

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

  parent reply	other threads:[~2010-06-02 18:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-28  0:29 [PATCH 0/8] HWPOISON for hugepage (v6) Naoya Horiguchi
2010-05-28  0:29 ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 1/8] hugetlb: move definition of is_vm_hugetlb_page() to hugepage_inline.h Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28 10:03   ` Mel Gorman
2010-05-28 10:03     ` Mel Gorman
2010-08-10 19:53     ` Wu Fengguang
2010-08-10 19:53       ` Wu Fengguang
2010-05-28  0:29 ` [PATCH 2/8] hugetlb, rmap: add reverse mapping for hugepage Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28 14:48   ` Mel Gorman
2010-05-28 14:48     ` Mel Gorman
2010-08-10 23:23     ` Wu Fengguang
2010-08-10 23:23       ` Wu Fengguang
2010-06-02 18:16   ` Andrew Morton [this message]
2010-06-02 18:16     ` Andrew Morton
2010-06-03  1:38     ` [PATCH] replace ifdef CONFIG_HUGETLBFS into ifdef CONFIG_HUGETLB_PAGE (Re: [PATCH 2/8] hugetlb, rmap: add reverse mapping for hugepage) Naoya Horiguchi
2010-06-03  1:38       ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 3/8] HWPOISON, hugetlb: enable error handling path for hugepage Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 4/8] HWPOISON, hugetlb: set/clear PG_hwpoison bits on hugepage Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 5/8] HWPOISON, hugetlb: maintain mce_bad_pages in handling hugepage error Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 6/8] HWPOISON, hugetlb: isolate corrupted hugepage Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 7/8] HWPOISON, hugetlb: detect hwpoison in hugetlb code Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-28  0:29 ` [PATCH 8/8] HWPOISON, hugetlb: support hwpoison injection for hugepage Naoya Horiguchi
2010-05-28  0:29   ` Naoya Horiguchi
2010-05-31  9:30 ` [PATCH 0/8] HWPOISON for hugepage (v6) Andi Kleen
2010-05-31  9:30   ` Andi Kleen
2010-05-31 10:17   ` Naoya Horiguchi
2010-05-31 10:17     ` Naoya Horiguchi

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=20100602111617.0c292178.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=aarcange@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.com \
    --cc=mel@csn.ul.ie \
    --cc=n-horiguchi@ah.jp.nec.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.