Re: [patches] malloc & madvise

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Tue, 10 Nov 2009, Richard Kralovic wrote:

> Joseph S. Myers wrote:
> > This patch is large enough we can't look at it in detail without a copyright
> > assignment on file at the FSF (such an assignment needs to name GLIBC; they
> > may want it to name EGLIBC as well).
> 
> Thank you for a fast answer. I have not made any assignment to FSF yet,
> but I am willing to do one. What steps are necessary to do it?

http://gcc.gnu.org/wiki/CopyrightAssignment

(as I noted above, the FSF may want the assignment to name both GLIBC and 
EGLIBC).

> > groups.  Allowing this to be configured when building EGLIBC, or just
> > changing the default unconditionally, is not of course a problem since it
> > doesn't affect the interface to EGLIBC; the problem would only be with 
> 
> In my opinion, it is reasonable to make this behavior the default one.
> Nevertheless, it might have a negative impact in certain situations.
> (Although my personal guess is that desktops and embedded systems are
> most likely to benefit from the change.)
> 
> Another way would be to not change the mallopt() at all, but keep the
> runtime tunability via environment variable. In this way, the binary
> compatibility would not be affected at all.
> 
> If any of these solutions were adopted in eglibc, it would allow an
> ordinary user to easily tune the system. Is any of them acceptable to be
> included in eglibc?

I'm certain some form of this should be acceptable.  The simplest would be 
to avoid runtime tunability.  malloc already accepts several environment 
variables, and I think we can safely define EGLIBC_* variables to be for 
EGLIBC-specific tuning (this doesn't affect malloc semantics, so it's 
harmless if someone uses the variable with a library that doesn't support 
it) - probably EGLIBC_MALLOC_<something>_.

It would also be worthwhile considering whether the performance cost from 
this can be reduced - for example, should it only be done after a few 
successive allocations have not reclaimed much of the free space?  (That 
may be a completely useless heuristic.  But there must be malloc 
benchmarks, and studies of what is or is not a good heuristic for malloc, 
out there.)

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx