All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Thorlton <athorlton@sgi.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>, Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 03/15] mm: thp: give transparent hugepage code a separate copy_page
Date: Wed, 4 Dec 2013 10:59:18 -0600	[thread overview]
Message-ID: <20131204165918.GA13191@sgi.com> (raw)
In-Reply-To: <1386060721-3794-4-git-send-email-mgorman@suse.de>

> -void copy_huge_page(struct page *dst, struct page *src)
> -{
> -	int i;
> -	struct hstate *h = page_hstate(src);
> -
> -	if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {

With CONFIG_HUGETLB_PAGE=n, the kernel fails to build, throwing this
error:

mm/migrate.c: In function a??copy_huge_pagea??:
mm/migrate.c:473: error: implicit declaration of function a??page_hstatea??

I got it to build by sticking the following into hugetlb.h:

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 4694afc..fd76912 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -403,6 +403,7 @@ struct hstate {};
 #define hstate_sizelog(s) NULL
 #define hstate_vma(v) NULL
 #define hstate_inode(i) NULL
+#define page_hstate(p) NULL
 #define huge_page_size(h) PAGE_SIZE
 #define huge_page_mask(h) PAGE_MASK
 #define vma_kernel_pagesize(v) PAGE_SIZE

I figure that the #define I stuck in isn't actually solving the real
problem, but it got things working again.

- Alex

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

WARNING: multiple messages have this Message-ID (diff)
From: Alex Thorlton <athorlton@sgi.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>, Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 03/15] mm: thp: give transparent hugepage code a separate copy_page
Date: Wed, 4 Dec 2013 10:59:18 -0600	[thread overview]
Message-ID: <20131204165918.GA13191@sgi.com> (raw)
In-Reply-To: <1386060721-3794-4-git-send-email-mgorman@suse.de>

> -void copy_huge_page(struct page *dst, struct page *src)
> -{
> -	int i;
> -	struct hstate *h = page_hstate(src);
> -
> -	if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {

With CONFIG_HUGETLB_PAGE=n, the kernel fails to build, throwing this
error:

mm/migrate.c: In function ‘copy_huge_page’:
mm/migrate.c:473: error: implicit declaration of function ‘page_hstate’

I got it to build by sticking the following into hugetlb.h:

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 4694afc..fd76912 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -403,6 +403,7 @@ struct hstate {};
 #define hstate_sizelog(s) NULL
 #define hstate_vma(v) NULL
 #define hstate_inode(i) NULL
+#define page_hstate(p) NULL
 #define huge_page_size(h) PAGE_SIZE
 #define huge_page_mask(h) PAGE_MASK
 #define vma_kernel_pagesize(v) PAGE_SIZE

I figure that the #define I stuck in isn't actually solving the real
problem, but it got things working again.

- Alex

  reply	other threads:[~2013-12-04 16:59 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-03  8:51 [PATCH 00/14] NUMA balancing segmentation faults candidate fix on large machines Mel Gorman
2013-12-03  8:51 ` Mel Gorman
2013-12-03  8:51 ` [PATCH 01/15] mm: numa: Do not batch handle PMD pages Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 02/15] mm: hugetlbfs: fix hugetlbfs optimization Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 03/15] mm: thp: give transparent hugepage code a separate copy_page Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-04 16:59   ` Alex Thorlton [this message]
2013-12-04 16:59     ` Alex Thorlton
2013-12-05 13:35     ` Mel Gorman
2013-12-05 13:35       ` Mel Gorman
2013-12-03  8:51 ` [PATCH 04/15] mm: numa: Serialise parallel get_user_page against THP migration Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03 23:07   ` Rik van Riel
2013-12-03 23:07     ` Rik van Riel
2013-12-03 23:54     ` Mel Gorman
2013-12-03 23:54       ` Mel Gorman
2013-12-03  8:51 ` [PATCH 05/15] mm: numa: Call MMU notifiers on " Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 06/15] mm: Clear pmd_numa before invalidating Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 07/15] mm: numa: Do not clear PMD during PTE update scan Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 08/15] mm: numa: Do not clear PTE for pte_numa update Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 09/15] mm: numa: Ensure anon_vma is locked to prevent parallel THP splits Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 10/15] mm: numa: Avoid unnecessary work on the failure path Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 11/15] sched: numa: Skip inaccessible VMAs Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:51 ` [PATCH 12/15] Clear numa on mprotect Mel Gorman
2013-12-03  8:51   ` Mel Gorman
2013-12-03  8:52 ` [PATCH 13/15] mm: numa: Avoid unnecessary disruption of NUMA hinting during migration Mel Gorman
2013-12-03  8:52   ` Mel Gorman
2013-12-03  8:52 ` [PATCH 14/15] mm: numa: Flush TLB if NUMA hinting faults race with PTE scan update Mel Gorman
2013-12-03  8:52   ` Mel Gorman
2013-12-03 23:07   ` Rik van Riel
2013-12-03 23:07     ` Rik van Riel
2013-12-03 23:46     ` Mel Gorman
2013-12-03 23:46       ` Mel Gorman
2013-12-04 14:33       ` Rik van Riel
2013-12-04 14:33         ` Rik van Riel
2013-12-04 16:07         ` Mel Gorman
2013-12-04 16:07           ` Mel Gorman
2013-12-05 15:40           ` Rik van Riel
2013-12-05 15:40             ` Rik van Riel
2013-12-05 19:54             ` Mel Gorman
2013-12-05 19:54               ` Mel Gorman
2013-12-05 20:05               ` Rik van Riel
2013-12-05 20:05                 ` Rik van Riel
2013-12-06  9:24                 ` Mel Gorman
2013-12-06  9:24                   ` Mel Gorman
2013-12-06 17:38                   ` Alex Thorlton
2013-12-06 17:38                     ` Alex Thorlton
2013-12-06 18:32                     ` Mel Gorman
2013-12-06 18:32                       ` Mel Gorman
2013-12-06 19:13           ` [PATCH 14/15] mm: fix TLB flush race between migration, and change_protection_range Rik van Riel
2013-12-06 19:13             ` Rik van Riel
2013-12-06 20:32             ` Christoph Lameter
2013-12-06 20:32               ` Christoph Lameter
2013-12-06 21:21               ` Rik van Riel
2013-12-06 21:21                 ` Rik van Riel
2013-12-07  0:25                 ` Christoph Lameter
2013-12-07  0:25                   ` Christoph Lameter
2013-12-07  3:14                   ` Rik van Riel
2013-12-07  3:14                     ` Rik van Riel
2013-12-09 16:00                     ` Christoph Lameter
2013-12-09 16:00                       ` Christoph Lameter
2013-12-09 16:27                       ` Mel Gorman
2013-12-09 16:27                         ` Mel Gorman
2013-12-09 16:59                         ` Christoph Lameter
2013-12-09 16:59                           ` Christoph Lameter
2013-12-09 21:01                           ` Rik van Riel
2013-12-09 21:01                             ` Rik van Riel

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=20131204165918.GA13191@sgi.com \
    --to=athorlton@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.