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>
