hammer: MAP_32BIT

DISCUSSION Ulrich Drepper 7 participants 29 messages May 9, 2003 – May 13, 2003

Share & tools

Ulrich Drepper

author

2003-05-09 07:23 UTC #0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To allocate stacks for the threads in nptl we currently use MAP_32BIT to make sure we get <4GB addresses for faster context switching time. But once the address space is allocated we have to resort to not using the flag. This means we have to make 2 mmap() calls, one with MAP_32BIT and if it fails another one without.

It would be much better if there would also be a MAP_32PREFER flag with the appropriate semantics. The failing mmap() calls seems to be quite expensive so programs with many threads are really punished a lot.

- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat --' drepper at redhat.com ---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+u1pF2ijCOnn/RHQRAk2IAKDAzXZUOsxMPAKkK9ivOz8o6zAaHQCeMC24 ysih3QB/I1w5MNXEIxNs284=
=2cet
-----END PGP SIGNATURE-----

Andi Kleen

2003-05-09 09:08 UTC #1 lore raw

Quoted 3 lines · Ulrich Drepper

It would be much better if there would also be a MAP_32PREFER flag with the appropriate semantics. The failing mmap() calls seems to be quite expensive so programs with many threads are really punished a lot.

That's just an inadequate data structure. It does an linear search of the VMAs and you probably have a lot of them. Before you add kludges like this better fix the data structure for fast free space lookup.

MAP_32BIT currently limits to the first 2GB only. That's needed because most programs use it to allocate modules for the small code model and that only supports 2GB (poster child for that is the X server) But for your application 4GB would be better. But adding another MAP_32BIT_4GB or so would be quite ugly. I considered making the address where mmap starts searching (TASK_UNMAPPED_BASE) settable using a prctl.

In some vendor kernels it's already in /proc/pid/mapped_base, but that is quite costly to change. That would probably give you the best of both, Just set it to a low value for the thread stacks and then reset it to the default.

I guess that would be the better solution for your stacks.

-Andi

[email protected]

2003-05-09 11:15 UTC #2 lore raw

Quoted 9 lines · Andi Kleen

Quoted 3 lines · Ulrich Drepper
It would be much better if there would also be a MAP_32PREFER flag with the appropriate semantics. The failing mmap() calls seems to be quite expensive so programs with many threads are really punished a lot.
That's just an inadequate data structure. It does an linear search of the VMAs and you probably have a lot of them. Before you add kludges like this better fix the data structure for fast free space lookup.

Quoted 6 lines

MAP_32BIT currently limits to the first 2GB only. That's needed because most programs use it to allocate modules for the small code model and that only supports 2GB (poster child for that is the X server) But for your application 4GB would be better. But adding another MAP_32BIT_4GB or so would be quite ugly. I considered making the address where mmap starts searching (TASK_UNMAPPED_BASE) settable using a prctl.

I have a potential use for mmap()ing in the low 4GB on x86_64. Sounds like your MAP_32BIT really is MAP_31BIT :-( which is too limiting. What about a more generic way of indicating which parts of the address space one wants? The simplest that would work for me is a single byte 'nrbits' specifying the target address space as [0 .. 2^nrbits-1]. This could be specified on a per-mmap() basis or as a settable process attribute.

/Mikael

Andi Kleen

2003-05-09 11:26 UTC #3 lore raw

Quoted 1 line · On Fri, May 09, 2003 at 01:28:11PM +0200, [email protected] wrote:

I have a potential use for mmap()ing in the low 4GB on x86_64.

Just use MAP_32BIT

Quoted 5 lines

Sounds like your MAP_32BIT really is MAP_31BIT :-( which is too limiting. What about a more generic way of indicating which parts of the address space one wants? The simplest that would work for me is a single byte 'nrbits' specifying the target address space as [0 .. 2^nrbits-1]. This could be specified on a per-mmap() basis or as a settable process attribute.

On x86-64 an mmap extension for that would be fine, but on i386 you get problems because mmap64() already maxes out the argument limit and you cannot add more.

You could only implement it with a structure in memory pointed to by an argument, which would be ugly.

prctl is probably better. You really want [start; end] right ?

Pity that task_struct is already so bloated, so every new entry hurts.

-Andi

[email protected]

2003-05-09 11:39 UTC #4 lore raw

Quoted 5 lines · Andi Kleen

Quoted 1 line · On Fri, May 09, 2003 at 01:28:11PM +0200, [email protected] wrote:
I have a potential use for mmap()ing in the low 4GB on x86_64.
Just use MAP_32BIT

Will that be corrected to use the full 4GB space? 2GB is too small.

Quoted 9 lines

Quoted 5 lines
Sounds like your MAP_32BIT really is MAP_31BIT :-( which is too limiting. What about a more generic way of indicating which parts of the address space one wants? The simplest that would work for me is a single byte 'nrbits' specifying the target address space as [0 .. 2^nrbits-1]. This could be specified on a per-mmap() basis or as a settable process attribute.
On x86-64 an mmap extension for that would be fine, but on i386 you get problems because mmap64() already maxes out the argument limit and you cannot add more.

This would only be used on x86_64. i386 compat is a non-issue. (This is for runtime systems stuff, not applictions.)

Quoted 1 line

prctl is probably better. You really want [start; end] right ?

I just want mmap() to return addresses that fit in 32 bits.

MAP_32BIT would do nicely, if it wasn't limited to 2GB.

/Mikael

Andi Kleen

2003-05-09 12:04 UTC #5 lore raw

Quoted 8 lines · On Fri, May 09, 2003 at 01:52:17PM +0200, [email protected] wrote:

Quoted 5 lines · Andi Kleen
Quoted 1 line · On Fri, May 09, 2003 at 01:28:11PM +0200, [email protected] wrote:
I have a potential use for mmap()ing in the low 4GB on x86_64.
Just use MAP_32BIT
Will that be corrected to use the full 4GB space? 2GB is too small.

That would break the X server.

But what you can do is to use mmap(0x1000, ....) and free the memory again if the result is bigger than 4GB. If you pass an non zero value as first argument but not MAP_FIXED it'll use the address argument as starting point for the search.

-Andi

H. Peter Anvin

2003-05-09 17:24 UTC #24 lore raw

In reply to Andi Kleen

Followup to:  <20030509092026.GA11012@averell>
By author:    Andi Kleen <[email protected]>
In newsgroup: linux.dev.kernel

Quoted 8 lines

MAP_32BIT currently limits to the first 2GB only. That's needed because most programs use it to allocate modules for the small code model and that only supports 2GB (poster child for that is the X server) But for your application 4GB would be better. But adding another MAP_32BIT_4GB or so would be quite ugly. I considered making the address where mmap starts searching (TASK_UNMAPPED_BASE) settable using a prctl.

MAP_31BIT would have been a better name...

-hpa

Signature · 3 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Ulrich Drepper

author

2003-05-09 17:27 UTC #25 lore raw

In reply to Andi Kleen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 3 lines · Andi Kleen

That's just an inadequate data structure. It does an linear search of the VMAs and you probably have a lot of them. Before you add kludges like this better fix the data structure for fast free space lookup.

If you mean the code in arch_get_unmapped_area(), yes, this needs fixing. In fact, Ingo has already a patch which brings back the performance of thread creation to what we had back in September/October.

Quoted 5 lines

In some vendor kernels it's already in /proc/pid/mapped_base, but that is quite costly to change. That would probably give you the best of both, Just set it to a low value for the thread stacks and then reset it to the default.
I guess that would be the better solution for your stacks.

Are you sure this is the best solution? It means the mmap regions for restricted 31/32 bit addresses and that for the normal, unrestricted mapping is continuous. This removes a lot of freedom in deciding where the unrestricted mappings are best located and it would make programs using threads have a very different memory layout. Not that it should make any difference; but I can here /them/ already scream that this breaks applications.

My kernel-uninformed opinion would be to keep the settings separate.

Oh, and please rename MAP_32BIT to MAP_31BIT. This will save nerves on all sides.

iD8DBQE+u+fi2ijCOnn/RHQRAqeBAKC3ZlSCNcw3f7SXahvxRc0WMupYgwCgyBGy fMqzCxWcx90e002CNUQqwgM=
=LDJf
-----END PGP SIGNATURE-----

H. Peter Anvin

2003-05-09 17:59 UTC #6 lore raw

In reply to Andi Kleen

Followup to:  <20030509113845.GA4586@averell>
By author:    Andi Kleen <[email protected]>
In newsgroup: linux.dev.kernel

Quoted 13 lines · On Fri, May 09, 2003 at 01:28:11PM +0200, [email protected] wrote:

Quoted 1 line
I have a potential use for mmap()ing in the low 4GB on x86_64.
Just use MAP_32BIT
Quoted 5 lines
Sounds like your MAP_32BIT really is MAP_31BIT :-( which is too limiting. What about a more generic way of indicating which parts of the address space one wants? The simplest that would work for me is a single byte 'nrbits' specifying the target address space as [0 .. 2^nrbits-1]. This could be specified on a per-mmap() basis or as a settable process attribute.

Quoted 4 lines

On x86-64 an mmap extension for that would be fine, but on i386 you get problems because mmap64() already maxes out the argument limit and you cannot add more.

How about this: since the address argument is basically unused anyway unless MAP_FIXED is set, how about a MAP_MAXADDR which interprets the address argument as the highest permissible address (or lowest nonpermissible address)?

-hpa

Signature · 3 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Ulrich Drepper

author

2003-05-09 19:12 UTC #7 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · H. Peter Anvin

How about this: since the address argument is basically unused anyway unless MAP_FIXED is set, how about a MAP_MAXADDR which interprets the address argument as the highest permissible address (or lowest nonpermissible address)?

You miss the point of my initial mail: I need a way to say "preferrably 32bit address, otherwise give me what you have". MAP_32BIT already provides a way to require 32 bit addresses.

iD8DBQE+vACE2ijCOnn/RHQRAl3rAKCYgj3LqvIDJ8Ny3pnii8bBvsbwrQCdGkg4 pnFnBmubkRnnsVfBSjDBBWQ=
=P8SV
-----END PGP SIGNATURE-----

H. Peter Anvin

2003-05-09 20:43 UTC #8 lore raw

Quoted 12 lines · Ulrich Drepper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · H. Peter Anvin
How about this: since the address argument is basically unused anyway unless MAP_FIXED is set, how about a MAP_MAXADDR which interprets the address argument as the highest permissible address (or lowest nonpermissible address)?

Quoted 4 lines

You miss the point of my initial mail: I need a way to say "preferrably 32bit address, otherwise give me what you have". MAP_32BIT already provides a way to require 32 bit addresses.

No, it requires 31-bit addresses, and there was a discussion about how some things need 31-bit and some 32-bit addresses. There might also be a need for 39-bit addresses, to be compatible with Linux 2.4.

MAP_MAXADDR_ADVISORY?

-hpa

Ulrich Drepper

author

2003-05-09 21:32 UTC #9 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 2 lines · H. Peter Anvin

No, it requires 31-bit addresses, and there was a discussion about how some things need 31-bit and some 32-bit addresses.

That's completely irrelevant to my point. Whether MAP_32BIT actually has a 31 bit limit or not doesn't matter, it's limited as well in the possible mmap blocks it can return.

The only thing I care about is to have a hint and not a fixed requirement for mmap(). All your proposals completely ignored this.

iD8DBQE+vCFk2ijCOnn/RHQRAnw1AKChzyuZ3g9iXAX5wH088rhko/s8YgCgku12 CayuZsLJGzPO//WCJVWyLxk=
=rkBk
-----END PGP SIGNATURE-----

H. Peter Anvin

2003-05-09 21:56 UTC #10 lore raw

Quoted 10 lines · Ulrich Drepper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · H. Peter Anvin
No, it requires 31-bit addresses, and there was a discussion about how some things need 31-bit and some 32-bit addresses.

Quoted 7 lines

That's completely irrelevant to my point. Whether MAP_32BIT actually has a 31 bit limit or not doesn't matter, it's limited as well in the possible mmap blocks it can return.
The only thing I care about is to have a hint and not a fixed requirement for mmap(). All your proposals completely ignored this.

Yes, but this is irrelevant to *MY* point... this discussion spawned a side discussion, and somehow you're upset that it's not addressing your concern but a different one... seems a bit ridiculous!

Anyway, I already posted that if we're adding MAP_MAXADDR we could also add MAP_MAXADDR_ADVISORY or something similar to that. On the other hand, how big of a performance issue is it really to call mmap() again in the failure scenario *only*?

-hpa

Timothy Miller

2003-05-09 22:04 UTC #13 lore raw

In reply to Ulrich Drepper

Quoted 10 lines · Ulrich Drepper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · H. Peter Anvin
No, it requires 31-bit addresses, and there was a discussion about how some things need 31-bit and some 32-bit addresses.

Quoted 7 lines

That's completely irrelevant to my point. Whether MAP_32BIT actually has a 31 bit limit or not doesn't matter, it's limited as well in the possible mmap blocks it can return.
The only thing I care about is to have a hint and not a fixed requirement for mmap(). All your proposals completely ignored this.

If your program is capable of handling an address with more than 32 bits, what point is there giving a hint? Either your program can handle 64-bit pointers or it cannot. Any program flexible enough to handle either size dynamically would expend enough overhead checking that it would be worse than if it just made a hard choice.

H. Peter Anvin

2003-05-09 22:07 UTC #14 lore raw

Quoted 7 lines · Timothy Miller

If your program is capable of handling an address with more than 32 bits, what point is there giving a hint? Either your program can handle 64-bit pointers or it cannot. Any program flexible enough to handle either size dynamically would expend enough overhead checking that it would be worse than if it just made a hard choice.

The purpose is that there is a slight task-switching speed advantage if the address is in the bottom 4 GB. Since this affects every process, and most processes use very little TLS, this is worthwhile.

This is fundamentally due to a K8 design flaw.

-hpa

Ulrich Drepper

author

2003-05-09 22:08 UTC #11 lore raw

In reply to H. Peter Anvin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 3 lines · H. Peter Anvin

On the other
hand, how big of a performance issue is it really to call mmap() again in the failure scenario *only*?

Just look at the code, it's very expensive. In the moment the mmap code has to sequentially look at the VMAs in question. If it fails it means it walked the entire data structure without success. Ingo's patch does not address this, it just makes successful allocation usually fast again.

iD8DBQE+vCmt2ijCOnn/RHQRAsUeAJ9gGIwIK+QKpSz15YDEaB5aISBwowCgjReV WSvgiDRcLX5bpla/Agikmj0=
=NSIn
-----END PGP SIGNATURE-----

H. Peter Anvin

2003-05-09 22:09 UTC #12 lore raw

Quoted 10 lines · Ulrich Drepper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · H. Peter Anvin
On the other
hand, how big of a performance issue is it really to call mmap() again in the failure scenario *only*?

Quoted 5 lines

Just look at the code, it's very expensive. In the moment the mmap code has to sequentially look at the VMAs in question. If it fails it means it walked the entire data structure without success. Ingo's patch does not address this, it just makes successful allocation usually fast again.

OK, maybe we should fix that instead :-/

-hpa

Ulrich Drepper

author

2003-05-09 22:10 UTC #18 lore raw

In reply to Timothy Miller

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 5 lines · Timothy Miller

If your program is capable of handling an address with more than 32 bits, what point is there giving a hint? Either your program can handle 64-bit pointers or it cannot. Any program flexible enough to handle either size dynamically would expend enough overhead checking that it would be worse than if it just made a hard choice.

Look at the x86-64 context switching code. If memory addressed by the GDT entries has a 32-bit address it uses a different method than for cases where the virtual address has more than 32 bits. This way of handling GDT entries is faster according to ak. So, it's not a correctness thing, it's a performance thing.

iD8DBQE+vCo82ijCOnn/RHQRAlGzAJ9Ti80kJMeecyxGikowWcfCAq0stwCfRVcQ Clui3Z6yKNSy3mu+phrY2FQ=
=GFwi
-----END PGP SIGNATURE-----

Timothy Miller

2003-05-09 22:29 UTC #15 lore raw

In reply to H. Peter Anvin

Quoted 10 lines · H. Peter Anvin

Quoted 6 lines · Timothy Miller
If your program is capable of handling an address with more than 32 bits, what point is there giving a hint? Either your program can handle 64-bit pointers or it cannot. Any program flexible enough to handle either size dynamically would expend enough overhead checking that it would be worse than if it just made a hard choice.

Quoted 5 lines

The purpose is that there is a slight task-switching speed advantage if the address is in the bottom 4 GB. Since this affects every process, and most processes use very little TLS, this is worthwhile.
This is fundamentally due to a K8 design flaw.

Is there an explicit check somewhere for this? Are the page tables laid out differently?

Timothy Miller

2003-05-09 22:36 UTC #19 lore raw

In reply to Ulrich Drepper

Quoted 13 lines · Ulrich Drepper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 5 lines · Timothy Miller
If your program is capable of handling an address with more than 32 bits, what point is there giving a hint? Either your program can handle 64-bit pointers or it cannot. Any program flexible enough to handle either size dynamically would expend enough overhead checking that it would be worse than if it just made a hard choice.

Quoted 6 lines

Look at the x86-64 context switching code. If memory addressed by the GDT entries has a 32-bit address it uses a different method than for cases where the virtual address has more than 32 bits. This way of handling GDT entries is faster according to ak. So, it's not a correctness thing, it's a performance thing.

Alright. Sounds great. So my next question is this:

Why does there ever need to be an explicit HINT that you would prefer a <32 bit address, when it's known a priori that <32 is better? Why doesn't the mapping code ALWAYS try to use 32-bit addresses before resorting to 64-bit?

Ulrich Drepper

author

2003-05-09 23:12 UTC #20 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Timothy Miller

Why does there ever need to be an explicit HINT that you would prefer a <32 bit address, when it's known a priori that <32 is better? Why doesn't the mapping code ALWAYS try to use 32-bit addresses before resorting to 64-bit?

Because not all memory is addressed via GDT entries. In fact, almost none is, only thread stacks and similar gimicks. If all mmap memory would by default be served from the low memory pool you soon run out of it and without any good reason.

iD8DBQE+vDjB2ijCOnn/RHQRAnHmAJ9V3BwxGTAUs7hw1YXowv0K0cEFFACePj6t vLI+B5BlYG4ox5WcyFrwg8A=
=IGO2
-----END PGP SIGNATURE-----

H. Peter Anvin

2003-05-09 23:12 UTC #16 lore raw

In reply to Timothy Miller

Quoted 10 lines · Timothy Miller

Quoted 6 lines
The purpose is that there is a slight task-switching speed advantage if the address is in the bottom 4 GB. Since this affects every process, and most processes use very little TLS, this is worthwhile.
This is fundamentally due to a K8 design flaw.
Is there an explicit check somewhere for this? Are the page tables laid out differently?

No, there are two ways to load the FS base register: use a descriptor, which is limited to 4 GB but is faster, or WRMSR, which is slower, but unlimited.

-hpa

Edgar Toernig

2003-05-09 23:49 UTC #21 lore raw

In reply to Ulrich Drepper

Quoted 9 lines · Ulrich Drepper

Quoted 4 lines
Why does there ever need to be an explicit HINT that you would prefer a <32 bit address, when it's known a priori that <32 is better? Why doesn't the mapping code ALWAYS try to use 32-bit addresses before resorting to 64-bit?
Because not all memory is addressed via GDT entries. In fact, almost none is, only thread stacks and similar gimicks. If all mmap memory would by default be served from the low memory pool you soon run out of it and without any good reason.

As if there are so many apps that would suffer from that...

Anyway, what's so bad about the idea someone (Linus?) suggested? Without MAP_FIXED the address given to mmap is already taken as a hint where to start looking for free memory. So use mmap(4GB,...) for regular memory and mmap(4kB, ...) for stacks. What's wrong with that? And if you are really frightend to run out of "low" memory make the above-4GB allocation the default for addr==0.

Ciao, ET.

Ulrich Drepper

author

2003-05-10 00:45 UTC #22 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 3 lines · Edgar Toernig

Anyway, what's so bad about the idea someone (Linus?) suggested? Without MAP_FIXED the address given to mmap is already taken as a hint where to start looking for free memory.

The kernel fortunately already defines some semantics to using a non-NULL first parameter without MAP_FIXED. It means: I prefer *exactly* this address. If it's not available, give me anything else. This is used and needed, for instance, when loading prelinked DSOs.

Now you want to give this another semantics. It would need at least one more MAP_* flag.

Anyway, I don't care what the solution looks like. Changing existing semantics should be out, that's the only requirement. Since I don't plan on doing the work I have nothing to decide.

iD8DBQE+vE6a2ijCOnn/RHQRAnxgAJ9ptrA6XRvLveB+xZyXZVTz4W8KjgCgkyUp BwOWiMQys/z8b6HZpneawJs=
=Ra9K
-----END PGP SIGNATURE-----

Andi Kleen

2003-05-10 01:35 UTC #26 lore raw

In reply to Ulrich Drepper

Quoted 8 lines · Ulrich Drepper

Quoted 6 lines
In some vendor kernels it's already in /proc/pid/mapped_base, but that is quite costly to change. That would probably give you the best of both, Just set it to a low value for the thread stacks and then reset it to the default.
I guess that would be the better solution for your stacks.
Are you sure this is the best solution? It means the mmap regions for

No, I'm not sure.

On further thinking the mapped_base would not be useful for you currently, because at least in the SuSE/AMD64 kernel it only applies to 32bit processes.

The real solution is probably to pass in the search start hint in mmap's address argument and not use MAP_32BiT.

e.g. use something like

	/* 
  	 * Current gcc still needs PROT_EXEC because it doesn't call
	 * __enable_execute_stack for trampolines yet.
 	 */
	stack = mmap(0x1000, stack_size, PROT_READ|PROT_WRITE|PROT_EXEC, 	
		     MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);

This will give you memory at the beginning of the address space and beyond 4GB if needed.

This may still be slow, but fixing the search algorithm is a different problem that can be tackled separately.

Quoted 2 lines

Oh, and please rename MAP_32BIT to MAP_31BIT. This will save nerves on all sides.

I bet changing it will cost more nerves in supporting all these people whose software doesn't compile anymore. And it's not really a lie. 2GB is 32bit too.

-Andi

Edgar Toernig

2003-05-10 02:40 UTC #23 lore raw

In reply to Ulrich Drepper

Quoted 1 line

Quoted 1 line
Anyway, what's so bad about the idea someone (Linus?) suggested?

[it was Andi]

Quoted 6 lines

Quoted 2 lines
Without MAP_FIXED the address given to mmap is already taken as a hint where to start looking for free memory.
The kernel fortunately already defines some semantics to using a non-NULL first parameter without MAP_FIXED. It means: I prefer *exactly* this address.

Yeah, ok.

Quoted 1 line

If it's not available, give me anything else.

And at least on older kernels (don't know about 2.5) it gives you not "anything" but the next free memory region above that address.

POSIX-draft6 about that topic:

"A non-zero value of addr is taken to be a suggestion of a
process address near which the mapping should be placed."

Quoted 2 lines

Now you want to give this another semantics. It would need at least one more MAP_* flag.

No new flag. No new semantic. Everything's already there...

Ciao, ET.

David Woodhouse

2003-05-10 19:57 UTC #27 lore raw

In reply to Andi Kleen

Quoted 6 lines · Andi Kleen

Quoted 2 lines
Oh, and please rename MAP_32BIT to MAP_31BIT. This will save nerves on all sides.
I bet changing it will cost more nerves in supporting all these people whose software doesn't compile anymore. And it's not really a lie. 2GB is 32bit too.

If that's _really_ an issue, then also provide MAP_32BIT which does what its name implies.

Anyone who was using MAP_32BIT in the knowledge that it really limits to 31 bits gets the breakage they deserve for not reporting and fixing the problem at the time.

Signature · 1 line

dwmw2

Timothy Miller

2003-05-13 14:08 UTC #17 lore raw

In reply to H. Peter Anvin

Quoted 17 lines · H. Peter Anvin

Quoted 9 lines · Timothy Miller
Quoted 5 lines
The purpose is that there is a slight task-switching speed advantage if the address is in the bottom 4 GB. Since this affects every process, and most processes use very little TLS, this is worthwhile.
This is fundamentally due to a K8 design flaw.
Is there an explicit check somewhere for this? Are the page tables laid out differently?
No, there are two ways to load the FS base register: use a descriptor, which is limited to 4 GB but is faster, or WRMSR, which is slower, but unlimited.

Quoted 12 lines · Ulrich Drepper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Timothy Miller
Why does there ever need to be an explicit HINT that you would prefer a <32 bit address, when it's known a priori that <32 is better? Why doesn't the mapping code ALWAYS try to use 32-bit addresses before resorting to 64-bit?

Quoted 4 lines

Because not all memory is addressed via GDT entries. In fact, almost none is, only thread stacks and similar gimicks. If all mmap memory would by default be served from the low memory pool you soon run out of it and without any good reason.

All I have to say is... I appreciate your patience with my ignorant questions. :)

H. Peter Anvin

2003-05-13 18:42 UTC #28 lore raw

In reply to David Woodhouse

Followup to:  <[email protected]>
By author:    David Woodhouse <[email protected]>
In newsgroup: linux.dev.kernel

Quoted 9 lines · Andi Kleen

Quoted 6 lines
Quoted 2 lines
Oh, and please rename MAP_32BIT to MAP_31BIT. This will save nerves on all sides.
I bet changing it will cost more nerves in supporting all these people whose software doesn't compile anymore. And it's not really a lie. 2GB is 32bit too.

Quoted 7 lines

If that's _really_ an issue, then also provide MAP_32BIT which does what its name implies.
Anyone who was using MAP_32BIT in the knowledge that it really limits to 31 bits gets the breakage they deserve for not reporting and fixing the problem at the time.

Agreed.

That being said, I think a more flexible scheme is called for; I still would like to suggest the MAP_MAXADDR and MAP_MAXADDR_ADVISORY flags that I mentioned earlier.

If people really want to retain the (rarely used) suggestion address, I'd suggest making the address argument a pointer to a structure:

struct map_maxaddr {
void *search; /* Suggestion address */
void *min; /* Lowest acceptable address */
void *max; /* Maximum acceptable address */
};

... however, it seems like overkill to me.

-hpa

Signature · 3 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64