David, Alex, got a sPAPR question for you.
Markus Armbruster <arm...@redhat.com> writes:
> Cc'ing in sPAPR maintainers...
[...]
> Let me spell things out a bit more, to make sure we all agree on what
> exactly we want to deprecate.
>
> After this series, -drive if=scsi works for the following machine types:
>
> * magnum pica61 LX SPARCClassic SPARCbook SS-10 SS-20 SS-4 SS-5 SS-600MP
> Voyager
>
> The machine has an onboard SCSI HBA, which adopts the drives with
> bus=0.. Drives with non-zero bus numbers stay orphaned. This is
> exactly how other interface types work.
>
> Except when additional HBAs get cold-plugged somehow, non-zero bus
> numbers can work; see below.
>
> * realview-eb realview-eb-mpcore versatileab versatilepb
>
> These create N lsi53c895a SCSI HBAs, where N is the largest value of
> bus. If N is too large, machine initialization fails with a "no
> slot/function available for lsi53c895a, all in use" error.
>
> This is just like the PC machine types work before this patch.
>
> * pseries-*
>
> Likewise, except create spapr-vscsi SCSI HBAs. Large N make machine
> initialization s-l-o-w. I tried to find out whether and how it fails
> when N is too large, but I lost patience.
Totally unscientific experiment: run "qemu-system-ppc64 -S -display none
-monitor stdio -M pseries,accel=qtest -drive if=scsi,media=cdrom,bus=N"
for various N and check SZ in ps, with "ps -C qemu-system-ppc64 -O sz".
Results:
N SZ
0 339413
10 353182
20 375342
30 405857
40 444716
50 491988
60 547582
70 611589
80 683916
90 764658
100 853743
Definitely super-linear. Is this expected?
No wonder my previous bus=999 experiement thrashed my machine;
extrapolating from the above I guesstimate SZ in the order of 50 million
pages.
Of course, asking for 1000 spapr-vscsi devices is silly, but trashing is
not a nice way to say "don't be silly". Should we reject bus=N when N
exceeds a certain limit? Care to suggest a limit?
[...]
