Messages in this thread | | | Date | Fri, 9 May 2003 13:28:11 +0200 | From | mikpe@csd ... | Subject | Re: hammer: MAP_32BIT |
| |
Andi Kleen writes: > On Fri, May 09, 2003 at 09:35:32AM +0200, Ulrich Drepper wrote: > > 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.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |