On Mon, 2017-12-11 at 13:02 +1100, Michael Ellerman wrote: > Cyril Bur <[email protected]> writes:
> > > On Tue, 2017-11-21 at 11:31 -0200, Gustavo Romero wrote: > > > Hi Cyril, > > > > > > On 21-11-2017 05:17, Cyril Bur wrote: > > > > Currently the tm-unavailable test spins for a fixed amount of time in > > > > an attempt to ensure the FPU/VMX/VSX facilities are off. This value was > > > > experimentally tested to be long enough. > > > > > > > > Problems may arise if kernel heuristics were to change. This patch > > > > should future proof this test. > > > > > > I've tried it on a VM running on '4.14.0-rc7' and apparently it gets stuck > > > pretty slow on calibration, since it ran ~7m without finding the correct > > > value > > > (before it would take about 3m), like: > > > > > > $ time ./tm-unavailable > > > Testing required spin time required for facility unavailable... > > > Trying 0x18000000... > > > Trying 0x19000000... > > > Trying 0x1a000000... > > > ... > > > Trying 0xfd000000... ^C > > > > > > real 7m15.304s > > > user 7m15.291s > > > sys 0m0.004s > > > > > > > Interesting! I didn't test in a VM. I guess hypervisor switching > > completely changes the heuristic. Ok I'll have to rethink. > > > > Maybe the increase should be a multiplier to get to a good state more > > quickly. > > Yeah this sucks in a VM: > > # /home/michael/tm-unavailable > Testing required spin time required for facility unavailable... > Trying 0x18000000... > Trying 0x19000000... > ... > Trying 0x110000000... > > etc. > > I got sick of waiting for it, but it's causing my selftests job to time > out so it must be taking > ~1 hour. > Yeah sorry, I'll see if I can come up with a better way for a VM. Needs a few more cycles from me. Cyril > cheers
