On 10/12/2011 10:02 PM, Alexander Graf wrote: > On 12.10.2011, at 20:05, Stefan Weil wrote: > > > Hello Avi, > > > > commit 36b58628 increased the alignment for some large memory > > blocks (typically the system RAM) to 2 MiB (QEMU_VMALLOC_ALIGN) > > on x86_64 Linux hosts. > > > > As far as I know, this was only required for KVM. > > > > There is a bad side effect of this increase: the Valgrind tool > > only supports an alignment of up to 1 MiB. It aborts execution > > with current QEMU for any target (even non-KVM targets). > > > > It might be possible to modify Valgrind (as far as I know this > > is already discussed), and of course I can also patch my local > > QEMU. Nevertheless, I think the alignment should be reduced > > again when there is no KVM support or KVM is disabled. > > Maybe the large alignment has other unwanted side effects. > > Actually, I'd much rather prefer to keep the differences between KVM and > non-KVM low here. THP can potentially also work on TCG, so the alignment > isn't completely moot here. Though it's certainly a lot less useful, as code > isn't directly executed from there and we the rest of the overhead is a lot > higher either way (especially the softmmu one).
Note thp will still work with tcg, even without alignment. The alignment requirement is specific to kvm. > Either way, why does valgrind break when we enforce big alignment? That > really sounds more like a valgrind bug than anything else. Memalign is there > for exactly that reason, no? > Agreed, seems like a valgrind limitation that needs to be lifted if possible. -- error compiling committee.c: too many arguments to function
