Re: Big reserved mappings on x86_64

From: Jakub Jelinek
Date: Wed Apr 25 2007 - 04:49:56 EST

On Wed, Apr 25, 2007 at 10:42:20AM +0200, Jan Engelhardt wrote:
> I actually took a look at `pmap $$`, which reveals that a lot of shared
> libraries map 2044K or 2048K unreadable-unwritable-private
> mappings...for _what_ purpose?
> 10:37 opteron:~ > pmap $$
> 4403: bash
> 2ae6cca70000 212K 172K 0K r-xp /lib64/
> 2ae6ccaa5000 2044K 0K 0K ---p /lib64/ <--
> 2ae6ccca4000 4K 4K 4K r--p /lib64/
> 2ae6ccca5000 28K 28K 28K rw-p /lib64/
> 2ae6cccac000 8K 8K 8K rw-p [anon]
> 2ae6cccae000 28K 16K 0K r-xp /lib64/
> 2ae6cccb5000 2048K 0K 0K ---p /lib64/ <--
> 2ae6cceb5000 8K 8K 8K rw-p /lib64/
> 2ae6cceb7000 320K 208K 0K r-xp /lib64/
> 2ae6ccf07000 2048K 0K 0K ---p /lib64/ <--
> 2ae6cd107000 48K 48K 48K r--p /lib64/
> 2ae6cd113000 28K 28K 28K rw-p /lib64/
> [...]
> What could these ominous mappings be? Does anyone else see that -
> perhaps someone with x86_64 && !(opensuse 10.2)?

While i386 only supports 4KB pages, x86_64 ELF objects ought to support
up to 2MB pages. The gap between read-only/executable and writable segments
is intentionally mapped PROT_NONE, so that other things aren't mapped in
between the segments.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at