Re: [patches] malloc & madvise

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

On Sat, 7 Nov 2009, Richard Kralovic wrote:

> As a proof of concept, I have implemented the madvise() calls in eglibc (the
> draft patch against eglibc 2.10.1 is attached). Some simple tests (running
> ghostscript on large pdfs, see the attached test script) shown that enabling
> madvise calls decreases the average resident memory by 14%, at the cost of
> 2.4% increase in running time. Hence, it is imho reasonable to give the user a
> possibility to enable the madvise calls() in free().
> 
> Would it be possible to include such a functionality in eglibc?

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).

Including it as something runtime tunable at runtime through mallopt is 
problematic because that's a public ABI and there are FSF GLIBC 
compatibility issues (and as an existing function you can't so readily put 
the new feature under a different symbol version).  
<http://www.eglibc.org/archives/patches/msg00642.html> discusses more the 
possibility of EGLIBC-specific functions under disabled-by-default option 
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 
runtime control through the existing mallopt function, which is the 
logical function to control such parameters but where any parameter value 
could be allocated by FSF GLIBC to do something different.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx