On Tue, 07 Jul 2020 14:00:06 +0200 Markus Armbruster <arm...@redhat.com> wrote:
> Paolo Bonzini <pbonz...@redhat.com> writes: > > > On 07/07/20 07:33, Markus Armbruster wrote: > >> Philippe Mathieu-Daudé <phi...@redhat.com> writes: > >> > >>> On 7/7/20 6:45 AM, Thomas Huth wrote: > >>>> On 27/05/2020 10.47, Markus Armbruster wrote: > >>>>> "info qom-tree" prints children in unstable order. This is a pain > >>>>> when diffing output for different versions to find change. Print it > >>>>> sorted. > >>>>> > >>>>> Signed-off-by: Markus Armbruster <arm...@redhat.com> > >>>>> --- > >>>>> qom/qom-hmp-cmds.c | 24 ++++++++++++++++-------- > >>>>> 1 file changed, 16 insertions(+), 8 deletions(-) > >>>> > >>>> Hi Markus, > >>>> > >>>> this patch causes a slow down of the qtests which becomes quite massive > >>>> when e.g. using the ppc64 and thourough testing. When I'm running > >>>> > >>>> QTEST_QEMU_BINARY="ppc64-softmmu/qemu-system-ppc64" time \ > >>>> ./tests/qtest/device-introspect-test -m slow | tail -n 10 > >>>> > >>>> the test runs for ca. 6m40s here before the patch got applied, and for > >>>> mor than 20 minutes after the patch got applied! > >> > >> That's surprising. > > > > It's a bit surprising indeed, but on the other hand using > > g_queue_insert_sorted results in a quadratic loop. > > The surprising part is that n turns out to be large enough for n^2 to > matter *that* much. Is this another consequence of the ludicrous number of QOM objects we create for LMB DRCs (one for every 256MiB of guest RAM)? Avoiding that is on my list. Though avoiding a n^2 behaviour here is probably a good idea anyway. -- David Gibson <dgib...@redhat.com> Principal Software Engineer, Virtualization, Red Hat
pgpURDPjG9G7x.pgp
Description: OpenPGP digital signature
