On Mon, 22 Oct 2012 08:36:33 -0700, Andi Kleen said:
> Thinking about it more PowerPC has a 16GB page, so we probably
> need to move this to prot.
Gaak - is that a typo? If not, what is the use case - allowing a small number
of
pages to cover all memory, with big wins on TLB hit ratios? I
I thought further about this and I think the whole issue is a non issue
anyways: MAP_UNINITIALIZED is NOMMU only and HUGETLBFS is MMU only.
My flags only make sense with HUGETLBFS.
So they can never coexist anyways. So there is no reason to not overlap.
So I think the original patch is ok and
On Tue, Oct 23, 2012 at 4:28 AM, Andi Kleen wrote:
> On Tue, Oct 23, 2012 at 12:44:24PM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2012-10-22 at 17:53 +0200, Michael Kerrisk (man-pages) wrote:
>>
>> > This is all seems to make an awful muck of the API...
>>
>> .../...
>>
>> > There seems to
On Tue, Oct 23, 2012 at 4:28 AM, Andi Kleen a...@linux.intel.com wrote:
On Tue, Oct 23, 2012 at 12:44:24PM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2012-10-22 at 17:53 +0200, Michael Kerrisk (man-pages) wrote:
This is all seems to make an awful muck of the API...
.../...
There seems
I thought further about this and I think the whole issue is a non issue
anyways: MAP_UNINITIALIZED is NOMMU only and HUGETLBFS is MMU only.
My flags only make sense with HUGETLBFS.
So they can never coexist anyways. So there is no reason to not overlap.
So I think the original patch is ok and
On Mon, 22 Oct 2012 08:36:33 -0700, Andi Kleen said:
Thinking about it more PowerPC has a 16GB page, so we probably
need to move this to prot.
Gaak - is that a typo? If not, what is the use case - allowing a small number
of
pages to cover all memory, with big wins on TLB hit ratios? I
On Mon, 2012-10-22 at 18:23 +0200, Michael Kerrisk (man-pages) wrote:
> Since PowerPC already allows 16GB page sizes, doesn't there need to be
> allowance for the possibility of future expansion? Choosing a larger
> minimum size (like 2^16) would allow that. Does the minimum size need
> to be 16k?
On Tue, Oct 23, 2012 at 12:44:24PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2012-10-22 at 17:53 +0200, Michael Kerrisk (man-pages) wrote:
>
> > This is all seems to make an awful muck of the API...
>
> .../...
>
> > There seems to be a reasonable argument here for an mmap3() with a
> >
On Mon, 2012-10-22 at 17:53 +0200, Michael Kerrisk (man-pages) wrote:
> This is all seems to make an awful muck of the API...
.../...
> There seems to be a reasonable argument here for an mmap3() with a
> 64-bit flags argument...
I tend to agree. There's a similar issue happening when we try
On Mon, 22 Oct 2012 15:27:33 +0200
Andi Kleen wrote:
> BTW seriously MAP_UNINITIALIZED? Who came up with that?
> MAP_COMPLETELY_INSECURE or MAP_INSANE would have been more appropiate.
heh. It's a NOMMU-only thing.
config MMAP_ALLOW_UNINITIALIZED
bool "Allow mmapped anonymous memory
> Since PowerPC already allows 16GB page sizes, doesn't there need to be
> allowance for the possibility of future expansion? Choosing a larger
> minimum size (like 2^16) would allow that. Does the minimum size need
> to be 16k? (Surely, if you want a HUGEPAGE, you want a bigger page
> than that?
On Mon, Oct 22, 2012 at 6:29 PM, Andi Kleen wrote:
>> Since PowerPC already allows 16GB page sizes, doesn't there need to be
>> allowance for the possibility of future expansion? Choosing a larger
>> minimum size (like 2^16) would allow that. Does the minimum size need
>> to be 16k? (Surely, if
>> >> But there seems an obvious solution here: given your value in those
>> >> bits (call it 'n'), the why not apply a multiplier. I mean, certainly
>> >> you never want a value <= 12 for n, and I suspect that the reasonable
>> >> minimum could be much larger (e.g., 2^16). Call that minimum M.
On Mon, Oct 22, 2012 at 05:53:45PM +0200, Michael Kerrisk (man-pages) wrote:
> I'm not sure whether anything is using the high 8 bits of prot, bun
> passing I note that there seems to be no check that the unused bits
> are zeroed so there's a small chance existing apps are passing random
>
On Mon, Oct 22, 2012 at 5:36 PM, Andi Kleen wrote:
>> Not sure of your notation there. I assume 31..27 means 5 bits (32
>> through to 28 inclusive, 27 excluded). That gives you just 2^31 ==
> [27...31]
(Hmm -- sleeping as I wrote that, but I at least got the end point right.)
> You're right
> Not sure of your notation there. I assume 31..27 means 5 bits (32
> through to 28 inclusive, 27 excluded). That gives you just 2^31 ==
[27...31]
You're right it's only 5 bits, so just 2GB.
Thinking about it more PowerPC has a 16GB page, so we probably
need to move this to prot.
However I'm
On Mon, Oct 22, 2012 at 3:35 PM, Andi Kleen wrote:
> On Mon, Oct 22, 2012 at 03:27:33PM +0200, Andi Kleen wrote:
>> > Maybe I am missing something obvious, but does this not conflict with
>> > include/uapi/asm-generic/mman-common.h:
>> >
>> > #ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
>> > # define
On Mon, Oct 22, 2012 at 03:27:33PM +0200, Andi Kleen wrote:
> > Maybe I am missing something obvious, but does this not conflict with
> > include/uapi/asm-generic/mman-common.h:
> >
> > #ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
> > # define MAP_UNINITIALIZED 0x400
> > ...
> >
> > 0x400 ==
> Maybe I am missing something obvious, but does this not conflict with
> include/uapi/asm-generic/mman-common.h:
>
> #ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
> # define MAP_UNINITIALIZED 0x400
> ...
>
> 0x400 == (1 << 26
>
You're right. Someone added that since I wrote the patch
Andi,
> +#define MAP_HUGE_2MB(21 << MAP_HUGE_SHIFT)
> +#define MAP_HUGE_1GB(30 << MAP_HUGE_SHIFT)
> +#define SHM_HUGE_SHIFT 26
> +#define SHM_HUGE_MASK 0x3f
> +#define SHM_HUGE_2MB(21 << SHM_HUGE_SHIFT)
> +#define SHM_HUGE_1GB(30 << SHM_HUGE_SHIFT)
Maybe I am missing something
Andi,
+#define MAP_HUGE_2MB(21 MAP_HUGE_SHIFT)
+#define MAP_HUGE_1GB(30 MAP_HUGE_SHIFT)
+#define SHM_HUGE_SHIFT 26
+#define SHM_HUGE_MASK 0x3f
+#define SHM_HUGE_2MB(21 SHM_HUGE_SHIFT)
+#define SHM_HUGE_1GB(30 SHM_HUGE_SHIFT)
Maybe I am missing something obvious, but
Maybe I am missing something obvious, but does this not conflict with
include/uapi/asm-generic/mman-common.h:
#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
# define MAP_UNINITIALIZED 0x400
...
0x400 == (1 26
You're right. Someone added that since I wrote the patch originally.
I
On Mon, Oct 22, 2012 at 03:27:33PM +0200, Andi Kleen wrote:
Maybe I am missing something obvious, but does this not conflict with
include/uapi/asm-generic/mman-common.h:
#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
# define MAP_UNINITIALIZED 0x400
...
0x400 == (1 26
On Mon, Oct 22, 2012 at 3:35 PM, Andi Kleen a...@firstfloor.org wrote:
On Mon, Oct 22, 2012 at 03:27:33PM +0200, Andi Kleen wrote:
Maybe I am missing something obvious, but does this not conflict with
include/uapi/asm-generic/mman-common.h:
#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
#
Not sure of your notation there. I assume 31..27 means 5 bits (32
through to 28 inclusive, 27 excluded). That gives you just 2^31 ==
[27...31]
You're right it's only 5 bits, so just 2GB.
Thinking about it more PowerPC has a 16GB page, so we probably
need to move this to prot.
However I'm not
On Mon, Oct 22, 2012 at 5:36 PM, Andi Kleen a...@linux.intel.com wrote:
Not sure of your notation there. I assume 31..27 means 5 bits (32
through to 28 inclusive, 27 excluded). That gives you just 2^31 ==
[27...31]
(Hmm -- sleeping as I wrote that, but I at least got the end point right.)
On Mon, Oct 22, 2012 at 05:53:45PM +0200, Michael Kerrisk (man-pages) wrote:
I'm not sure whether anything is using the high 8 bits of prot, bun
passing I note that there seems to be no check that the unused bits
are zeroed so there's a small chance existing apps are passing random
garbage
But there seems an obvious solution here: given your value in those
bits (call it 'n'), the why not apply a multiplier. I mean, certainly
you never want a value = 12 for n, and I suspect that the reasonable
minimum could be much larger (e.g., 2^16). Call that minimum M. Then
you could
On Mon, Oct 22, 2012 at 6:29 PM, Andi Kleen a...@linux.intel.com wrote:
Since PowerPC already allows 16GB page sizes, doesn't there need to be
allowance for the possibility of future expansion? Choosing a larger
minimum size (like 2^16) would allow that. Does the minimum size need
to be 16k?
Since PowerPC already allows 16GB page sizes, doesn't there need to be
allowance for the possibility of future expansion? Choosing a larger
minimum size (like 2^16) would allow that. Does the minimum size need
to be 16k? (Surely, if you want a HUGEPAGE, you want a bigger page
than that? I am
On Mon, 22 Oct 2012 15:27:33 +0200
Andi Kleen a...@firstfloor.org wrote:
BTW seriously MAP_UNINITIALIZED? Who came up with that?
MAP_COMPLETELY_INSECURE or MAP_INSANE would have been more appropiate.
heh. It's a NOMMU-only thing.
config MMAP_ALLOW_UNINITIALIZED
bool Allow mmapped
On Mon, 2012-10-22 at 17:53 +0200, Michael Kerrisk (man-pages) wrote:
This is all seems to make an awful muck of the API...
.../...
There seems to be a reasonable argument here for an mmap3() with a
64-bit flags argument...
I tend to agree. There's a similar issue happening when we try to
On Tue, Oct 23, 2012 at 12:44:24PM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2012-10-22 at 17:53 +0200, Michael Kerrisk (man-pages) wrote:
This is all seems to make an awful muck of the API...
.../...
There seems to be a reasonable argument here for an mmap3() with a
64-bit flags
On Mon, 2012-10-22 at 18:23 +0200, Michael Kerrisk (man-pages) wrote:
Since PowerPC already allows 16GB page sizes, doesn't there need to be
allowance for the possibility of future expansion? Choosing a larger
minimum size (like 2^16) would allow that. Does the minimum size need
to be 16k?
On Sat, Oct 20, 2012 at 12:48 AM, Andi Kleen wrote:
> From: Andi Kleen
>
> 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
From: Andi Kleen
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
From: Andi Kleen a...@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
On Sat, Oct 20, 2012 at 12:48 AM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@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
38 matches
Mail list logo
