All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hillf Danton <dhillf@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v6
Date: Sat, 20 Oct 2012 11:39:52 +0800	[thread overview]
Message-ID: <CAJd=RBAABS5Vt7pquAxfbhPZzAb1n-qM_VRTwXUc0uQRU1Ky0A@mail.gmail.com> (raw)
In-Reply-To: <1350665289-7288-1-git-send-email-andi@firstfloor.org>

On Sat, Oct 20, 2012 at 12:48 AM, Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> There was some desire in large applications using MAP_HUGETLB/SHM_HUGETLB
> to use 1GB huge pages on some mappings, and stay with 2MB on others. This
> is useful together with NUMA policy: use 2MB interleaving on some mappings,
> but 1GB on local mappings.
>
> This patch extends the IPC/SHM syscall interfaces slightly to allow specifying
> the page size.
>
> It borrows some upper bits in the existing flag arguments and allows encoding
> the log of the desired page size in addition to the *_HUGETLB flag.
> When 0 is specified the default size is used, this makes the change fully
> compatible.
>
> Extending the internal hugetlb code to handle this is straight forward. Instead
> of a single mount it just keeps an array of them and selects the right
> mount based on the specified page size. When no page size is specified
> it uses the mount of the default page size.
>
> The change is not visible in /proc/mounts because internal mounts
> don't appear there. It also has very little overhead: the additional
> mounts just consume a super block, but not more memory when not used.
>
> I also exported the new flags to the user headers
> (they were previously under __KERNEL__). Right now only symbols
> for x86 and some other architecture for 1GB and 2MB are defined.
> The interface should already work for all other architectures
> though.  Only architectures that define multiple hugetlb sizes
> actually need it (that is currently x86, tile, powerpc). However
> tile and powerpc have user configurable hugetlb sizes, so it's
> not easy to add defines. A program on those architectures would
> need to query sysfs and use the appropiate log2.
>
> v2: Port to new tree. Fix unmount.
> v3: Ported to latest tree.
> v4: Ported to latest tree. Minor changes for review feedback. Updated
> description.
> v5: Remove unnecessary prototypes to fix merge error (Hillf Danton)
> v6: Rebased. Fix some unlikely error paths (Hillf Danton)
> Acked-by: Rik van Riel <riel@redhat.com>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Hillf Danton <dhillf@gmail.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---

Thanks:)

Acked-by: Hillf Danton <dhillf@gmail.com>

WARNING: multiple messages have this Message-ID (diff)
From: Hillf Danton <dhillf@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v6
Date: Sat, 20 Oct 2012 11:39:52 +0800	[thread overview]
Message-ID: <CAJd=RBAABS5Vt7pquAxfbhPZzAb1n-qM_VRTwXUc0uQRU1Ky0A@mail.gmail.com> (raw)
In-Reply-To: <1350665289-7288-1-git-send-email-andi@firstfloor.org>

On Sat, Oct 20, 2012 at 12:48 AM, Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> There was some desire in large applications using MAP_HUGETLB/SHM_HUGETLB
> to use 1GB huge pages on some mappings, and stay with 2MB on others. This
> is useful together with NUMA policy: use 2MB interleaving on some mappings,
> but 1GB on local mappings.
>
> This patch extends the IPC/SHM syscall interfaces slightly to allow specifying
> the page size.
>
> It borrows some upper bits in the existing flag arguments and allows encoding
> the log of the desired page size in addition to the *_HUGETLB flag.
> When 0 is specified the default size is used, this makes the change fully
> compatible.
>
> Extending the internal hugetlb code to handle this is straight forward. Instead
> of a single mount it just keeps an array of them and selects the right
> mount based on the specified page size. When no page size is specified
> it uses the mount of the default page size.
>
> The change is not visible in /proc/mounts because internal mounts
> don't appear there. It also has very little overhead: the additional
> mounts just consume a super block, but not more memory when not used.
>
> I also exported the new flags to the user headers
> (they were previously under __KERNEL__). Right now only symbols
> for x86 and some other architecture for 1GB and 2MB are defined.
> The interface should already work for all other architectures
> though.  Only architectures that define multiple hugetlb sizes
> actually need it (that is currently x86, tile, powerpc). However
> tile and powerpc have user configurable hugetlb sizes, so it's
> not easy to add defines. A program on those architectures would
> need to query sysfs and use the appropiate log2.
>
> v2: Port to new tree. Fix unmount.
> v3: Ported to latest tree.
> v4: Ported to latest tree. Minor changes for review feedback. Updated
> description.
> v5: Remove unnecessary prototypes to fix merge error (Hillf Danton)
> v6: Rebased. Fix some unlikely error paths (Hillf Danton)
> Acked-by: Rik van Riel <riel@redhat.com>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Hillf Danton <dhillf@gmail.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---

Thanks:)

Acked-by: Hillf Danton <dhillf@gmail.com>

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

  reply	other threads:[~2012-10-20  3:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19 16:48 [PATCH] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v6 Andi Kleen
2012-10-19 16:48 ` Andi Kleen
2012-10-20  3:39 ` Hillf Danton [this message]
2012-10-20  3:39   ` Hillf Danton
2012-10-22 11:27 ` Michael Kerrisk
2012-10-22 11:27   ` Michael Kerrisk
2012-10-22 13:27   ` Andi Kleen
2012-10-22 13:27     ` Andi Kleen
2012-10-22 13:35     ` Andi Kleen
2012-10-22 13:35       ` Andi Kleen
2012-10-22 13:56       ` Michael Kerrisk (man-pages)
2012-10-22 13:56         ` Michael Kerrisk (man-pages)
2012-10-22 15:36         ` Andi Kleen
2012-10-22 15:36           ` Andi Kleen
2012-10-22 15:53           ` Michael Kerrisk (man-pages)
2012-10-22 15:53             ` Michael Kerrisk (man-pages)
2012-10-22 16:11             ` Andi Kleen
2012-10-22 16:11               ` Andi Kleen
2012-10-22 16:23               ` Michael Kerrisk (man-pages)
2012-10-22 16:23                 ` Michael Kerrisk (man-pages)
2012-10-22 16:29                 ` Andi Kleen
2012-10-22 16:29                   ` Andi Kleen
2012-10-22 16:42                   ` Michael Kerrisk (man-pages)
2012-10-22 16:42                     ` Michael Kerrisk (man-pages)
2012-10-23  1:45                 ` Benjamin Herrenschmidt
2012-10-23  1:45                   ` Benjamin Herrenschmidt
2012-10-23  1:44             ` Benjamin Herrenschmidt
2012-10-23  1:44               ` Benjamin Herrenschmidt
2012-10-23  2:28               ` Andi Kleen
2012-10-23  2:28                 ` Andi Kleen
2012-10-23  7:37                 ` Michael Kerrisk (man-pages)
2012-10-23  7:37                   ` Michael Kerrisk (man-pages)
2012-10-23 13:39                   ` Andi Kleen
2012-10-23 13:39                     ` Andi Kleen
2012-10-23 22:56           ` Valdis.Kletnieks
2012-10-22 21:39     ` Andrew Morton
2012-10-22 21:39       ` Andrew Morton

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='CAJd=RBAABS5Vt7pquAxfbhPZzAb1n-qM_VRTwXUc0uQRU1Ky0A@mail.gmail.com' \
    --to=dhillf@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.