Re: posix_memalign

[Bruno Haible]

Eric Blake wrote:
> > We have a 'pagealign_alloc' module that does not waste memory.
> 
> Alas, pagealign_alloc is currently GPLv3+, although if libvirt were to
> use it in place of posix_memalign, it would have to be LGPLv2+.  It
> looks like Jim, Paul, and Bruno are the only contributors so far.

Don't forget Derek Robert Price, who initially wrote this code.

> How important is it that our special-case allocation/free in
> pagealign_alloc() remain GPL?

Ask the 4 copyright holders.

> > I wouldn't like to slow down free(), which is used in many places, for the
> > sake of posix_memalign() (as opposed to pagealign_alloc()) which is rarely
> > used.
> 
> It would only be slowed down on systems where we cannot otherwise get
> aligned allocations.  Per your research:
> 
> Minix 3.1.8   not page-aligned at all
> AIX 5.1       not page-aligned at all
> HP-UX 11      not page-aligned at all
> IRIX 6.5      not page-aligned at all
> OSF/1 5.1     not page-aligned at all
> Solaris 10    not page-aligned at all
> Cygwin 1.5.x  not page-aligned at all
> mingw         not page-aligned at all
> MSVC 9        not page-aligned at all

This is a whole lot of systems!

> Or maybe we introduce an
> LGPLv2+ posix_memalign that wastefully overallocates and slows down
> free(), and leave pagealign_alloc() as GPLv3+, as a way to encourage
> licensing improvements for people that care about efficiency on
> deficient platforms.

If the issue with the license is that big, please provide a posix_memalign-
like function that has its own _free function, under LGPLv2+.

I don't want to hear reports like "my program got 5% slower after I started
using gnulib module xyz". Overriding free() to do nontrivial stuff has the
potential for a 5% slowdown. If we can't provide a POSIX API portably, let's
instead choose the most similar possible API.

> Thinking aloud here, another possibility might be to use mmap() to
> provide posix_memalign() at page boundaries, as well as reserving the
> previous page as an unmapped guard page.  Most implementations of
> malloc() have a free() that assumes a header was present immediately
> before the pointer returned by malloc(), and would thus fault in free()
> while trying to access the header just before a pointer returned by
> posix_memalign. ...

Nice trick, but unfortunately not usable for functions that are meant to
be called from libraries. Signal handling has global impact on a program.

Bruno
-- 
In memoriam Willy Cohn <http://de.wikipedia.org/wiki/Willy_Cohn>