This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable


On Sat, Jul 21, 2012 at 08:18:14AM +0200, Jakub Jelinek wrote:
> On Fri, Jul 20, 2012 at 03:44:17PM -0700, Roland McGrath wrote:
> > > I believe you are talking about the madvise mode that has been discussed a
> > > few years ago, but unfortunately wasn't implemented in the end.
> > 
> > I was speaking in the abstract about what the interface contract for
> > MADV_DONTNEED is and thus the range of behaviors that some kernel (Linux
> > or otherwise) might one day implement.
> 
> If MADV_DONTNEED isn't any faster than munmap + mmap anymore (benchmarks?),

munmap+mmap is not possible; there's an extremely dangerous race
condition if you do that. You must use mmap with MAP_FIXED.

> then here is a link to the MADV_FREE stuff that was being proposed and
> discussed:
> http://kerneltrap.org/mailarchive/linux-kernel/2007/4/17/77912
> I believe the reason it hasn't been committed in the end was that
> MADV_DONTNEED looked fast enough for the kernel people for the workloads
> that were tested.  If that is not the case anymore and you can show
> workloads where MADV_DONTNEED is too slow, perhaps it might be time to
> attempt to ressurrect MADV_FREE, benchmark it and ask for inclusion...

I don't see the difference in MADV_FREE and mmap+MAP_FIZED+PROT_NONE
over top of the original map. If the latter is not fast enough it
should just be optimized for this special case since portable software
will already be using it for this purpose.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]