From: Mike Kravetz <mike.kravetz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC v5 PATCH 8/9] hugetlbfs: add hugetlbfs_fallocate()
Date: Fri, 24 Jul 2015 09:18:35 -0700 [thread overview]
Message-ID: <55B2655B.4040001@oracle.com> (raw)
In-Reply-To: <20150724062533.GA4622@dhcp22.suse.cz>
On 07/23/2015 11:25 PM, Michal Hocko wrote:
> I hope this is the current version of the pathc - I somehow got lost in
> last submissions where the discussion happens in v4 thread. This version
> seems to have the same issue:
Yes, Michal this issue exists in the version put into mmotm and was
noticed by kbuild test robot and Stephen in linux-next build.
Your patch below is the most obvious. Thanks! However, is this
the preferred method of handling this type of issue? Is it
preferred to create wrappers for the code which handles numa
policy? Then there could be two versions of the wrapper: one
if CONFIG_NUMA is defined and one (a no-op) if not. I am happy
with either, but am a relative newbie in this area so am looking
for a little guidance.
--
Mike Kravetz
> ---
> From 04c37a979c5ce8cd39d3243e4e2c12905e4f1e6e Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Fri, 24 Jul 2015 08:14:32 +0200
> Subject: [PATCH] mmotm:
> hugetlbfs-new-huge_add_to_page_cache-helper-routine-fix
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> hugetlbfs_fallocate relies on CONFIG_NUMA and fails to compile otherwise.
> This just makes the code compile but it seems it begs for a better solution.
>
> fs/hugetlbfs/inode.c: In function a??hugetlbfs_fallocatea??:
> fs/hugetlbfs/inode.c:578:13: error: a??struct vm_area_structa?? has no member named a??vm_policya??
> pseudo_vma.vm_policy =
> ^
> fs/hugetlbfs/inode.c:579:4: error: implicit declaration of function a??mpol_shared_policy_lookupa?? [-Werror=implicit-function-declaration]
> mpol_shared_policy_lookup(&HUGETLBFS_I(inode)->policy,
> ^
> fs/hugetlbfs/inode.c:595:28: error: a??struct vm_area_structa?? has no member named a??vm_policya??
> mpol_cond_put(pseudo_vma.vm_policy);
> ^
> fs/hugetlbfs/inode.c:601:27: error: a??struct vm_area_structa?? has no member named a??vm_policya??
> mpol_cond_put(pseudo_vma.vm_policy);
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> fs/hugetlbfs/inode.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index d977cae89d29..dfca09218d77 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -575,9 +575,11 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
> }
>
> /* Get policy based on index */
> +#ifdef CONFIG_NUMA
> pseudo_vma.vm_policy =
> mpol_shared_policy_lookup(&HUGETLBFS_I(inode)->policy,
> index);
> +#endif
>
> /* addr is the offset within the file (zero based) */
> addr = index * hpage_size;
> @@ -592,13 +594,17 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
> if (page) {
> put_page(page);
> mutex_unlock(&hugetlb_fault_mutex_table[hash]);
> +#ifdef CONFIG_NUMA
> mpol_cond_put(pseudo_vma.vm_policy);
> +#endif
> continue;
> }
>
> /* Allocate page and add to page cache */
> page = alloc_huge_page(&pseudo_vma, addr, avoid_reserve);
> +#ifdef CONFIG_NUMA
> mpol_cond_put(pseudo_vma.vm_policy);
> +#endif
> if (IS_ERR(page)) {
> mutex_unlock(&hugetlb_fault_mutex_table[hash]);
> error = PTR_ERR(page);
>
--
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:[~2015-07-24 16:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 0:38 [RFC v5 PATCH 0/9] hugetlbfs: add fallocate support Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 1/9] mm/hugetlb: add region_del() to delete a specific range of entries Mike Kravetz
2015-06-29 21:47 ` Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 2/9] mm/hugetlb: expose hugetlb fault mutex for use by fallocate Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 3/9] hugetlbfs: hugetlb_vmtruncate_list() needs to take a range to delete Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 4/9] hugetlbfs: truncate_hugepages() takes a range of pages Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 5/9] mm/hugetlb: vma_has_reserves() needs to handle fallocate hole punch Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 6/9] mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 7/9] hugetlbfs: New huge_add_to_page_cache helper routine Mike Kravetz
2015-06-23 0:38 ` [RFC v5 PATCH 8/9] hugetlbfs: add hugetlbfs_fallocate() Mike Kravetz
2015-07-24 6:25 ` Michal Hocko
2015-07-24 16:18 ` Mike Kravetz [this message]
2015-07-27 7:07 ` Michal Hocko
2015-06-23 0:38 ` [RFC v5 PATCH 9/9] mm: madvise allow remove operation for hugetlbfs Mike Kravetz
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=55B2655B.4040001@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=hch@infradead.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rientjes@google.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;
as well as URLs for NNTP newsgroup(s).