* [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
@ 2011-10-12 18:05 Stefan Weil
2011-10-12 20:02 ` Alexander Graf
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Weil @ 2011-10-12 18:05 UTC (permalink / raw)
To: Avi Kivity; +Cc: QEMU Developers
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.
The code is in oslib-posix.c (target independent) and needs
something like kvm_enabled() (currently a macro). What would
you suggest? Maybe you can provide a patch.
Kind regards,
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 18:05 [Qemu-devel] 2 MiB alignment in qemu_vmalloc() Stefan Weil
@ 2011-10-12 20:02 ` Alexander Graf
2011-10-12 20:41 ` Stefan Weil
2011-10-16 8:41 ` Avi Kivity
0 siblings, 2 replies; 9+ messages in thread
From: Alexander Graf @ 2011-10-12 20:02 UTC (permalink / raw)
To: Stefan Weil; +Cc: Avi Kivity, QEMU Developers
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).
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?
Alex
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 20:02 ` Alexander Graf
@ 2011-10-12 20:41 ` Stefan Weil
2011-10-12 20:47 ` Alexander Graf
2011-10-16 8:41 ` Avi Kivity
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Weil @ 2011-10-12 20:41 UTC (permalink / raw)
To: Alexander Graf; +Cc: Avi Kivity, QEMU Developers
Am 12.10.2011 22:02, schrieb Alexander Graf:
> 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).
> 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?
>
>
> Alex
Actually, there is even a difference between KVM (x86_64) and KVM (non
x86_64)
in the current code: only x86_64 hosts use the 2 MiB alignment.
Valgrind breaks because it has an assertion which limits the alignment.
This limitation was already discussed in 2008 and still exists in latest
Ubuntu and other distributions (and also in latest Valgrind SVN trunk).
Therefore I don't expect that it will be fixed soon.
See these bug reports, for example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489297
http://bugs.kde.org/show_bug.cgi?id=203877
Cheers,
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 20:41 ` Stefan Weil
@ 2011-10-12 20:47 ` Alexander Graf
2011-10-12 21:19 ` Stefan Weil
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Graf @ 2011-10-12 20:47 UTC (permalink / raw)
To: Stefan Weil; +Cc: Avi Kivity, QEMU Developers
On 12.10.2011, at 22:41, Stefan Weil wrote:
> Am 12.10.2011 22:02, schrieb Alexander Graf:
>> 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).
>> 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?
>>
>>
>> Alex
>
> Actually, there is even a difference between KVM (x86_64) and KVM (non x86_64)
> in the current code: only x86_64 hosts use the 2 MiB alignment.
Right. It might make sense to find a reasonable alignment for all archs and just set it to that. I vote for 16MB :).
> Valgrind breaks because it has an assertion which limits the alignment.
> This limitation was already discussed in 2008 and still exists in latest
> Ubuntu and other distributions (and also in latest Valgrind SVN trunk).
>
> Therefore I don't expect that it will be fixed soon.
>
> See these bug reports, for example:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489297
> http://bugs.kde.org/show_bug.cgi?id=203877
Well, yes, my point is that it's a bug in valgrind that should be fixed. I don't think we should special-case QEMU because of bugs in debugging software :)
Alex
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 20:47 ` Alexander Graf
@ 2011-10-12 21:19 ` Stefan Weil
2011-10-12 21:30 ` Alexander Graf
2011-10-13 7:56 ` Gerd Hoffmann
0 siblings, 2 replies; 9+ messages in thread
From: Stefan Weil @ 2011-10-12 21:19 UTC (permalink / raw)
To: Alexander Graf; +Cc: Avi Kivity, QEMU Developers
Am 12.10.2011 22:47, schrieb Alexander Graf:
> Well, yes, my point is that it's a bug in valgrind that should be
> fixed. I don't think we should special-case QEMU because of bugs in
> debugging software :)
>
> Alex
Yes, the valgrind bug should be fixed. I don't know why it isn't,
but that's not the point:
Valgrind is very valuable for finding certain kinds of bugs in QEMU
which we want to find and fix (I hope we agree on this).
Therefore developers should be able to use it.
Today, they cannot use Valgrind with QEMU out-of-the box,
because they get an assertion. Some developers will stop here.
Others will ask Google, look in Valgrind's code and spend some
time to find and fix the problem before they start using
Valgrind to find QEMU bugs.
They could have spent their time better.
I can try to make QEMU more useable with Valgrind by changing
the QEMU code (which was Valgrind compatible up to Avi's change).
I cannot change the Valgrind code, and even if I could, it would
take a lot of time until all Linux distributions would include a
fixed Valgrind :-(
If all existing gdb versions did not work with QEMU,
but there were a simple QEMU change which made them work,
what would you do?
Cheers,
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 21:19 ` Stefan Weil
@ 2011-10-12 21:30 ` Alexander Graf
2011-10-13 7:56 ` Gerd Hoffmann
1 sibling, 0 replies; 9+ messages in thread
From: Alexander Graf @ 2011-10-12 21:30 UTC (permalink / raw)
To: Stefan Weil; +Cc: Avi Kivity, QEMU Developers
On 12.10.2011, at 23:19, Stefan Weil wrote:
> Am 12.10.2011 22:47, schrieb Alexander Graf:
>> Well, yes, my point is that it's a bug in valgrind that should be fixed. I don't think we should special-case QEMU because of bugs in debugging software :)
>>
>> Alex
>
> Yes, the valgrind bug should be fixed. I don't know why it isn't,
> but that's not the point:
>
> Valgrind is very valuable for finding certain kinds of bugs in QEMU
> which we want to find and fix (I hope we agree on this).
> Therefore developers should be able to use it.
>
> Today, they cannot use Valgrind with QEMU out-of-the box,
> because they get an assertion. Some developers will stop here.
> Others will ask Google, look in Valgrind's code and spend some
> time to find and fix the problem before they start using
> Valgrind to find QEMU bugs.
>
> They could have spent their time better.
>
> I can try to make QEMU more useable with Valgrind by changing
> the QEMU code (which was Valgrind compatible up to Avi's change).
>
> I cannot change the Valgrind code, and even if I could, it would
> take a lot of time until all Linux distributions would include a
> fixed Valgrind :-(
>
> If all existing gdb versions did not work with QEMU,
> but there were a simple QEMU change which made them work,
> what would you do?
I would add a command line option to modify the alignment in runtime, defaulting it to something sane (16MB), so you can work around bugs in vagrind with a simple parameter :)
Alex
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 21:19 ` Stefan Weil
2011-10-12 21:30 ` Alexander Graf
@ 2011-10-13 7:56 ` Gerd Hoffmann
2011-10-13 13:23 ` Paolo Bonzini
1 sibling, 1 reply; 9+ messages in thread
From: Gerd Hoffmann @ 2011-10-13 7:56 UTC (permalink / raw)
To: Stefan Weil; +Cc: QEMU Developers, Alexander Graf, Avi Kivity
Hi,
> I can try to make QEMU more useable with Valgrind by changing
> the QEMU code (which was Valgrind compatible up to Avi's change).
Is there some way for apps to figure they are running in valgrind?
Then we could choose a different alignment automagically.
Who aborts btw? Is this valgrind itself? Or qemu due to memalign
failing? In case of the latter we could simply catch it and try again
with another alignment ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-13 7:56 ` Gerd Hoffmann
@ 2011-10-13 13:23 ` Paolo Bonzini
0 siblings, 0 replies; 9+ messages in thread
From: Paolo Bonzini @ 2011-10-13 13:23 UTC (permalink / raw)
To: qemu-devel
On 10/13/2011 09:56 AM, Gerd Hoffmann wrote:
>
> Is there some way for apps to figure they are running in valgrind?
> Then we could choose a different alignment automagically.
Yes, valgrind.h (on RH distros that's in package valgrind-devel; there
is a valgrind.pc file to add the correct include path) provides a
RUNNING_ON_VALGRIND macro.
Paolo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] 2 MiB alignment in qemu_vmalloc()
2011-10-12 20:02 ` Alexander Graf
2011-10-12 20:41 ` Stefan Weil
@ 2011-10-16 8:41 ` Avi Kivity
1 sibling, 0 replies; 9+ messages in thread
From: Avi Kivity @ 2011-10-16 8:41 UTC (permalink / raw)
To: Alexander Graf; +Cc: Stefan Weil, QEMU Developers
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-10-16 8:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-12 18:05 [Qemu-devel] 2 MiB alignment in qemu_vmalloc() Stefan Weil
2011-10-12 20:02 ` Alexander Graf
2011-10-12 20:41 ` Stefan Weil
2011-10-12 20:47 ` Alexander Graf
2011-10-12 21:19 ` Stefan Weil
2011-10-12 21:30 ` Alexander Graf
2011-10-13 7:56 ` Gerd Hoffmann
2011-10-13 13:23 ` Paolo Bonzini
2011-10-16 8:41 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).