Re: mmap behavior
- From: "Kaz Kylheku" <kkylheku@xxxxxxxxx>
- Date: 20 Sep 2006 16:02:57 -0700
ochedru@xxxxxxxxx wrote:
This actually causes some trouble because my application relies on
vsize to perform some self-maintenance tasks.
With this fake 1GB overhead, this mechanism is broken.
Your program is broken, because it depends on dubious or even buggy
behavior.
Is there any workaround? Is there another way to reserve an address
space range for shared mappings?
mmap doesn't reserve, it allocates.
There is no sure-fire way to reserve an address space range without
actually mapping it.
A PROT_NONE mapping is a real mapping. It's not valid for mmap to
simply not create the mapping because the protection is set to
PROT_NONE. A mapped page that cannot be read or written is not the same
thing as an unmapped page. It's a mapped page which happens not to have
write permission or read permission.
See, you can adjust the protection later with mprotect. You can't
adjust the protection on unmapped memory with mprotect. The mapping has
to exist.
Also, I could not find anything in /proc that would allow me to get the
"real" vsize.
Can't your program keep track of what it considers to be "not real" and
subtract it?
.
- References:
- mmap behavior
- From: ochedru
- Re: mmap behavior
- From: David Schwartz
- Re: mmap behavior
- From: ochedru
- mmap behavior
- Prev by Date: Re: How to configure Linux kernel source tree hierarchy
- Next by Date: Re: link a serial char and network driver
- Previous by thread: Re: mmap behavior
- Next by thread: what to do on linux?
- Index(es):
Relevant Pages
|