Version: 3.4.1 (using KDE 4.3.0) Compiler: gcc 4.1 OS: Linux Installed from: Fedora RPMs An application that causes VG_(arena_memalign) crash is allocating memory with posix_memalign() using 8 MB alignment. 8MB alignment is required for DMA access to a disk array, memory chunks have to be page-aligned. Memcheck prevents the calls to memalign() with values greater than 1Mb. I'd like to ask this check to be changed to 8388608 in m_mallocfree.c. Memory-page alignemnt is a fairly common scenario. PS: This is a follow-up to an old bug report https://bugs.kde.org/show_bug.cgi?id=187760
*** Bug 272940 has been marked as a duplicate of this bug. ***
I'd like to understand what the reasoning was for limiting the alignment before changing this, but we have had several requests for it now, so it does seem like something we need to give some thought to. Does anybody know why we have the limit? Presumably it's because of the potential wastefulness because we have to allocate a large block in order to ensure the alignment? It looks like we return the spare memory to the heap though, and the larger the alignment the larger that spare fragment will be and the more useful it is likely to be for future allocations?
I have the same problem regarding a 4MBytes alignment request. Alignment on 4MBytes a condition to (eventually) benefit from Linux' Transparent Huge Page http://lwn.net/Articles/423584/ . Even if it's not a concern when running under valgrind, having to build a dedicated test program with alignment disabled, is not 'user-friendly'. Why not add an option to memcheck to allow user defined max alignment ?
Same problem here. qemu-system-ppc64 -M pseries requires a 16M aligned allocation for the MMU hash table which fails. 16M can be reasonably common (it's the standard huge page size on ppc64). What is the reason for having a limit to begin with ?
Maximum increased to 16 Mb in revision 12642 Note : after discussion, it was deemed better to keep a check on plausible alignment maximum, rather than authorize full freedom.
*** Bug 301229 has been marked as a duplicate of this bug. ***
Thanks !