September 7, 2025 at 10:21 PM, "BALATON Zoltan" wrote:
> On Fri, 5 Sep 2025, Julian Ganz wrote:
> 
> > 
> > September 5, 2025 at 9:25 PM, "BALATON Zoltan" wrote:
> > > The default may better be what the larger group needs. Even then distros 
> > > may still change the default so it would be best if the overhead can be 
> > > minimised even if enabled. I think the log infrastructure does that, 
> > > would a similar solution work here?
> > > 
> > >  For testing I've found that because embedded PPC CPUs have a software 
> > > controlled MMU (and in addition to that QEMU may flush TLB entries too 
> > > often) running something that does a lot of memory access like runnung 
> > > the STREAM benchmark on sam460ex is hit by this IIRC but anything else 
> > > causing a lot of interrupts like reading from emulated disk or sound is 
> > > probably affected as well. I've tried to optimise PPC exception handling 
> > > a bit before but whenever I optimise something it is later undone by 
> > > other changes not caring about performance.
> > > 
> >  I could try running the benchmark on multiple versions:
> > 
> >  * qemu with plugins disabled,
> >  * with plugins enabled but without these patches and
> >  * with plugins enabled and with these patches.
> > 
> >  However, I'll likely only report back with results next week, though.
> >  Do you happen to have an image you can point me to? Either something
> >  that has the benchmark already or some unixoid running on the platform?
> >  I'm currently not motivated enough to cook up some bare-metal testbed
> >  for a platform I'm not familiar with.
> > 
> I don't have ready images to test embedded PPC MMU exceptions which I think 
> this may affect most. I had an image for pegasos2 for a general test used 
> here:
> https://lists.nongnu.org/archive/html/qemu-discuss/2023-12/msg00008.html
> but that machine has a G4 CPU which has hardware MMU so is likely not 
> affected.

I ran this test anyway, because it was easy enough to run. Tweaked the
script to do 10 runs, each with one of the aforementioned variants.
Isolating the time stats printed gives you the following:

Qemu with patches and plugins enabled:

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2557x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2621x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2536x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2394x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2529x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2565x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2456x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2450x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2526x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2528x|    0:00

Qemu (6a9fa5ef3230a7d51e0d953a59ee9ef10af705b8) without these patches,
but plugins enabled:

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2309x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2399x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2547x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2511x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2265x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2156x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2401x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2460x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2472x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2370x|    0:00

Qemu (6a9fa5ef3230a7d51e0d953a59ee9ef10af705b8) without these patches,
with plugins disabled:

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2478x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2509x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2500x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2019x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2439x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2453x|    0:00
  1149/1149  (100%)|    0:25/    0:25|    0:25/    0:25|   1.1945x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2331x|    0:00
  1149/1149  (100%)|    0:23/    0:23|    0:23/    0:23|   1.2510x|    0:00
  1149/1149  (100%)|    0:24/    0:24|    0:24/    0:24|   1.2467x|    0:00

So nothing to see here. If anything, we see a slight reduction in
runtime with these patches, which doesn't makes any sense. I did not do
a fresh clean build for those, and the order I ran the tests may have
had some influence on the results.

> I have uploaded some PPC binaries for the STREAM benchmark that I tested with 
> before here:
> http://zero.eik.bme.hu/~balaton/qemu/stream-test.zip
> which may excercise this if run on sam460ex or ppce500 machines but I don't 
> have a scripted test case for that. There is some docs on how to run Linux on 
> these machines here:
> https://www.qemu.org/docs/master/system/target-ppc.html

Thanks, I'll have alook at how to run those over the course of this
week.

> Alternatively maybe running a disk IO benchmark on an emulated IDE controller 
> using PIO mode or some other device that generates a lots of interrupts may 
> test this. I think you can use the "info irq" command in QEMU Monitor to 
> check how many interrupts you get.

I started writing a small exception/interrupt torture test for the
PPC440 with the help of robots. If and when I'm finishing it I'll do
some measurements with that.

Regards,
Julian

Reply via email to