Summary: | Increase maximum allowed alignment for memalign() | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Alex Ivershen <alex.ivershen> |
Component: | general | Assignee: | Nicholas Nethercote <njn> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | benh, kuszmaul, madcoder, njn, philippe.waroquiers, tom, yann |
Priority: | NOR | ||
Version: | 3.4.1 | ||
Target Milestone: | blocking3.5.1 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Alex Ivershen
2009-08-14 20:24:24 UTC
*** 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 ! |