On Mon, Sep 03, 2018 at 02:25:50PM +0200, Andrew Jones wrote:
> On Mon, Sep 03, 2018 at 12:58:45PM +0200, Christoffer Dall wrote:
> > The current MAX_SMP check launches QEMU for every value of the SMP
> > parameter to check if the SMP parameter based on the native is higher
> > than the QEMU maximum supported configuration.
> >
> > On something like a TX2, which has 224 threads, this takes a very long
> > time where the test script just sits there with no output.
> >
> > Reduce the wait time by taking the log2 of MAX_SMP in each iteration of
> > the loop instead.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@xxxxxxx>
> > ---
> > scripts/runtime.bash | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/runtime.bash b/scripts/runtime.bash
> > index a31ae91..1e2c288 100644
> > --- a/scripts/runtime.bash
> > +++ b/scripts/runtime.bash
> > @@ -140,5 +140,5 @@ function run()
> > # just remove it...
> > while $RUNTIME_arch_run _NO_FILE_4Uhere_ -smp $MAX_SMP \
> > |& grep -qi 'exceeds max CPUs'; do
> > - ((--MAX_SMP))
> > + MAX_SMP=$((MAX_SMP >> 1))
> > done
> > --
> > 2.7.4
> >
>
> Reviewed-by: Andrew Jones <drjones@xxxxxxxxxx>
>
>
> Someday I should move this into arch-specific code and replace
> it with something like:
>
> if gic-v3
> MAX_SMP = MIN(_SC_NPROCESSORS_ONLN, 255)
Not quite, becasue QEMU can't seem to support more than 123 CPUs with it
current default set of parameters used by kvmtool at least. But perhaps
that's being fixed with some changes to QEMU/KVM (I lost track).
Thanks for the reviews.
Christoffer
> else
> MAX_SMP = MIN(_SC_NPROCESSORS_ONLN, 8)
>
> If other archs ever care about it (they currently don't), then
> they can implement their own thing.
>
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
