Re: Slow down with: 'Make "info qom-tree" show children sorted'
On Thu, 16 Jul 2020 07:37:17 +0200 Markus Armbruster wrote: > David Gibson writes: > > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > > > ... as you say, 256 shouldn't really be a problem. I was concerned > > about LMB DRCs rather than PCI DRCs. To have that show up, you might > > need to create a machine with a large difference between initial memory > > and maxmem - I think you'll get a DRC object for every 256MiB in there, > > which can easily get into the thousands for large (potential) memory > > VMs. > > Okay, I can reproduce: with -m 256,128G, /machine has 549 children, of > which 511 are spapr-drc-lmb. Ok. > > I don't know what the config was that showed up this problem in the > > first place, and whether that could be the case there. > > Thomas reported device-introspect-test -m slow has become much slower > for ppc64. Bisection traced it to my commit e8c9e65816 "qom: Make "info > qom-tree" show children sorted". Uses default memory size, no > spapr-drc-lmb as far as I remember. Ok, I think that nixes my theory. > >> > Though avoiding a n^2 behaviour here is probably a good > >> > idea anyway. > >> > >> Agreed. > > Patch posted: > > Subject: [PATCH for-5.1 5/5] qom: Make info qom-tree sort children more > efficiently > Message-Id: <20200714160202.3121879-6-arm...@redhat.com> > -- David Gibson Principal Software Engineer, Virtualization, Red Hat pgpNJKUKCBNgO.pgp Description: OpenPGP digital signature
Re: Slow down with: 'Make "info qom-tree" show children sorted'
David Gibson writes: > On Mon, 13 Jul 2020 18:13:42 +0200 > Markus Armbruster wrote: > >> David Gibson writes: >> >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> >> >> >> 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. >> >> You're talking about machine pseries, I presume. > > Yes. > >> With >> print_qom_composition() patched to print the number of children, I get >> >> $ echo -e 'info qom-tree\nq' | >> ../qemu/bld/ppc64-softmmu/qemu-system-ppc64 -S -display none -M pseries >> -accel qtest -monitor stdio | grep '###' | sort | uniq -c | sort -k 3n >> 360 ### 0 children >> 5 ### 1 children >> 5 ### 2 children >> 2 ### 3 children >> 1 ### 4 children >> 1 ### 15 children >> 1 ### 16 children >> 1 ### 18 children >> 1 ### 37 children >> 1 ### 266 children >> >> The outlier is >> >> /device[5] (spapr-pci-host-bridge) >> >> due to its 256 spapr-drc-pci children. > > Right, that's one for each possible PCI slot on the bus. That will be > reduced by the idea I have in mind for this, but... > >> I found quite a few machines with similar outliers. ARM machines nuri >> and smdkc210 together take the cake: they each have a node with 513 >> children. >> >> My stupid n^2 sort is unnoticable in normal, human usage even for n=513. > > ... as you say, 256 shouldn't really be a problem. I was concerned > about LMB DRCs rather than PCI DRCs. To have that show up, you might > need to create a machine with a large difference between initial memory > and maxmem - I think you'll get a DRC object for every 256MiB in there, > which can easily get into the thousands for large (potential) memory > VMs. Okay, I can reproduce: with -m 256,128G, /machine has 549 children, of which 511 are spapr-drc-lmb. > I don't know what the config was that showed up this problem in the > first place, and whether that could be the case there. Thomas reported device-introspect-test -m slow has become much slower for ppc64. Bisection traced it to my commit e8c9e65816 "qom: Make "info qom-tree" show children sorted". Uses default memory size, no spapr-drc-lmb as far as I remember. >> > Though avoiding a n^2 behaviour here is probably a good >> > idea anyway. >> >> Agreed. Patch posted: Subject: [PATCH for-5.1 5/5] qom: Make info qom-tree sort children more efficiently Message-Id: <20200714160202.3121879-6-arm...@redhat.com>
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On Mon, 13 Jul 2020 18:13:42 +0200 Markus Armbruster wrote: > David Gibson writes: > > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > >> > >> 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. > > You're talking about machine pseries, I presume. Yes. > With > print_qom_composition() patched to print the number of children, I get > > $ echo -e 'info qom-tree\nq' | > ../qemu/bld/ppc64-softmmu/qemu-system-ppc64 -S -display none -M pseries > -accel qtest -monitor stdio | grep '###' | sort | uniq -c | sort -k 3n > 360 ### 0 children > 5 ### 1 children > 5 ### 2 children > 2 ### 3 children > 1 ### 4 children > 1 ### 15 children > 1 ### 16 children > 1 ### 18 children > 1 ### 37 children > 1 ### 266 children > > The outlier is > > /device[5] (spapr-pci-host-bridge) > > due to its 256 spapr-drc-pci children. Right, that's one for each possible PCI slot on the bus. That will be reduced by the idea I have in mind for this, but... > I found quite a few machines with similar outliers. ARM machines nuri > and smdkc210 together take the cake: they each have a node with 513 > children. > > My stupid n^2 sort is unnoticable in normal, human usage even for n=513. ... as you say, 256 shouldn't really be a problem. I was concerned about LMB DRCs rather than PCI DRCs. To have that show up, you might need to create a machine with a large difference between initial memory and maxmem - I think you'll get a DRC object for every 256MiB in there, which can easily get into the thousands for large (potential) memory VMs. I don't know what the config was that showed up this problem in the first place, and whether that could be the case there. > > Though avoiding a n^2 behaviour here is probably a good > > idea anyway. > > Agreed. -- David Gibson Principal Software Engineer, Virtualization, Red Hat pgpfwUjJtV_T5.pgp Description: OpenPGP digital signature
Re: Slow down with: 'Make "info qom-tree" show children sorted'
David Gibson writes: > On Tue, 07 Jul 2020 14:00:06 +0200 > Markus Armbruster wrote: > >> Paolo Bonzini writes: >> >> > On 07/07/20 07:33, Markus Armbruster wrote: >> >> Philippe Mathieu-Daudé 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 >> > --- >> > 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. You're talking about machine pseries, I presume. With print_qom_composition() patched to print the number of children, I get $ echo -e 'info qom-tree\nq' | ../qemu/bld/ppc64-softmmu/qemu-system-ppc64 -S -display none -M pseries -accel qtest -monitor stdio | grep '###' | sort | uniq -c | sort -k 3n 360 ### 0 children 5 ### 1 children 5 ### 2 children 2 ### 3 children 1 ### 4 children 1 ### 15 children 1 ### 16 children 1 ### 18 children 1 ### 37 children 1 ### 266 children The outlier is /device[5] (spapr-pci-host-bridge) due to its 256 spapr-drc-pci children. I found quite a few machines with similar outliers. ARM machines nuri and smdkc210 together take the cake: they each have a node with 513 children. My stupid n^2 sort is unnoticable in normal, human usage even for n=513. > Though avoiding a n^2 behaviour here is probably a good > idea anyway. Agreed.
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On Tue, 07 Jul 2020 14:00:06 +0200 Markus Armbruster wrote: > Paolo Bonzini writes: > > > On 07/07/20 07:33, Markus Armbruster wrote: > >> Philippe Mathieu-Daudé 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 > > --- > > 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 Principal Software Engineer, Virtualization, Red Hat pgpURDPjG9G7x.pgp Description: OpenPGP digital signature
Re: Slow down with: 'Make "info qom-tree" show children sorted'
Daniel P. Berrangé writes: > On Tue, Jul 07, 2020 at 06:45:57AM +0200, 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 >> > --- >> > 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! > > I think the test case itself could be optimized. Currently it does > approx > >for each device type > info qom-tree > device_addr type,help > info qom-tree > > it compares the before/after qom-tree to look for stray objects or > to try to trigger crashes. > > The info qom-tree calls could be pushed outside the loop > >info qom-tree >for each device type > device_addr type,help >info qom-tree > > Taking /x86_64/device/introspect/concrete/defaults/pc-q35-5.1 as a > example, this change is the difference between 20 seconds running and > 3 seconds running. Patch? > Reverting Markus' change actually didn't make much difference, only > reducing the 20 seconds to 17 seconds. I found and plugged a memory leak. I haven't checked its impact on test performance. > The downside is that if there is a stray object/crash, it would not > immediately associate with the device type. I'm not sure that's a > real problem though. Especially if we are running this as pre-merge > CI we'll only need to look at the patch series to find the broken > device. If this is quick enough that we can run it as standard, > instead of only with -m slow, then its a net win I think. Easier investigation of failures is a valid argument, but not at this price. Our "make check" is painfully slow.
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On Tue, Jul 07, 2020 at 02:00:06PM +0200, Markus Armbruster wrote: > Paolo Bonzini writes: > > > On 07/07/20 07:33, Markus Armbruster wrote: > >> Philippe Mathieu-Daudé 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 > > --- > > 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. The test suite as a whole is more like n^3 because it is running so many repeats of "info qom-tree" Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Slow down with: 'Make "info qom-tree" show children sorted'
Paolo Bonzini writes: > On 07/07/20 07:33, Markus Armbruster wrote: >> Philippe Mathieu-Daudé 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 > --- > 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. > It should probably > be fixed by using g_queue_sort, or switching to g_list_prepend+g_list_sort. Yes. Additional ideas on how to make the test less wasteful elsewhere in the thread.
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On 07/07/20 11:40, Daniel P. Berrangé wrote: > > The info qom-tree calls could be pushed outside the loop > >info qom-tree >for each device type > device_addr type,help >info qom-tree > > Taking /x86_64/device/introspect/concrete/defaults/pc-q35-5.1 as a > example, this change is the difference between 20 seconds running and > 3 seconds running. Or even, saving half the runtime: info qom-tree for each device type device_addr type,help info qom-tree Paolo > Reverting Markus' change actually didn't make much difference, only > reducing the 20 seconds to 17 seconds. > > The downside is that if there is a stray object/crash, it would not > immediately associate with the device type. I'm not sure that's a > real problem though. Especially if we are running this as pre-merge > CI we'll only need to look at the patch series to find the broken > device. If this is quick enough that we can run it as standard, > instead of only with -m slow, then its a net win I think.
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On Tue, Jul 07, 2020 at 06:45:57AM +0200, 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 > > --- > > 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! I think the test case itself could be optimized. Currently it does approx for each device type info qom-tree device_addr type,help info qom-tree it compares the before/after qom-tree to look for stray objects or to try to trigger crashes. The info qom-tree calls could be pushed outside the loop info qom-tree for each device type device_addr type,help info qom-tree Taking /x86_64/device/introspect/concrete/defaults/pc-q35-5.1 as a example, this change is the difference between 20 seconds running and 3 seconds running. Reverting Markus' change actually didn't make much difference, only reducing the 20 seconds to 17 seconds. The downside is that if there is a stray object/crash, it would not immediately associate with the device type. I'm not sure that's a real problem though. Especially if we are running this as pre-merge CI we'll only need to look at the patch series to find the broken device. If this is quick enough that we can run it as standard, instead of only with -m slow, then its a net win I think. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On 07/07/20 10:46, Daniel P. Berrangé wrote: > On Tue, Jul 07, 2020 at 06:45:57AM +0200, Thomas Huth wrote: >> Sure, we can work around that problem in the CI (Alex has already a >> patch queued), but still, is there something you could do about this >> massive slowdown? > > I think the answer is to stop using q_queue_insert_sorted(). The impl of > it looks like it is quadratic in complexity. Instead store the objects > in a plain array and then use qsort() at the end. g_list_sort uses a mergesort, so it's a good choice as well. But yeah GPtrArray is another possibility. Paolo
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On Tue, Jul 07, 2020 at 06:45:57AM +0200, 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 > > --- > > 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! > > This causes our gitlab CI to constantly fail since the patch got merged, > since the testing time now exceeds the 1h time limit: > > https://gitlab.com/qemu-project/qemu/-/pipelines/156767175 > > Sure, we can work around that problem in the CI (Alex has already a > patch queued), but still, is there something you could do about this > massive slowdown? I think the answer is to stop using q_queue_insert_sorted(). The impl of it looks like it is quadratic in complexity. Instead store the objects in a plain array and then use qsort() at the end. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Slow down with: 'Make "info qom-tree" show children sorted'
On 07/07/20 07:33, Markus Armbruster wrote: > Philippe Mathieu-Daudé 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 --- 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. It should probably be fixed by using g_queue_sort, or switching to g_list_prepend+g_list_sort. Paolo >> Argh, yesterday I reviewed again all the range except this patch... not >> sure why as looking at it now it is obvious. >> >>> This causes our gitlab CI to constantly fail since the patch got merged, >>> since the testing time now exceeds the 1h time limit: >>> >>> https://gitlab.com/qemu-project/qemu/-/pipelines/156767175 >>> >>> Sure, we can work around that problem in the CI (Alex has already a >>> patch queued), but still, is there something you could do about this >>> massive slowdown? >> >> Suggestion: add a '-u' option for unsorted mode, to use in qtests. >> >> Humans want the new behavior (default: sorted). > > Last resort. > > I'll look into speeding up the sort first. > > Work-around: drop -m slow until we get this sorted (pardon the pun). >
Re: Slow down with: 'Make "info qom-tree" show children sorted'
Philippe Mathieu-Daudé 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 >>> --- >>> 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. > Argh, yesterday I reviewed again all the range except this patch... not > sure why as looking at it now it is obvious. > >> This causes our gitlab CI to constantly fail since the patch got merged, >> since the testing time now exceeds the 1h time limit: >> >> https://gitlab.com/qemu-project/qemu/-/pipelines/156767175 >> >> Sure, we can work around that problem in the CI (Alex has already a >> patch queued), but still, is there something you could do about this >> massive slowdown? > > Suggestion: add a '-u' option for unsorted mode, to use in qtests. > > Humans want the new behavior (default: sorted). Last resort. I'll look into speeding up the sort first. Work-around: drop -m slow until we get this sorted (pardon the pun).
Re: Slow down with: 'Make "info qom-tree" show children sorted'
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 >> --- >> 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! Argh, yesterday I reviewed again all the range except this patch... not sure why as looking at it now it is obvious. > This causes our gitlab CI to constantly fail since the patch got merged, > since the testing time now exceeds the 1h time limit: > > https://gitlab.com/qemu-project/qemu/-/pipelines/156767175 > > Sure, we can work around that problem in the CI (Alex has already a > patch queued), but still, is there something you could do about this > massive slowdown? Suggestion: add a '-u' option for unsorted mode, to use in qtests. Humans want the new behavior (default: sorted). Regards, Phil.
Slow down with: 'Make "info qom-tree" show children sorted'
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 > --- > 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! This causes our gitlab CI to constantly fail since the patch got merged, since the testing time now exceeds the 1h time limit: https://gitlab.com/qemu-project/qemu/-/pipelines/156767175 Sure, we can work around that problem in the CI (Alex has already a patch queued), but still, is there something you could do about this massive slowdown? Thanks, Thomas
