[LTP] [PATCH] syscalls/perf_event_open03: skip test on slower systems

[Li Wang]

Jan Stancek <jstancek@redhat.com> wrote:

Some systems (specially with combination of -debug kernel
> with KASAN enabled) have trouble completing this test
> in specified timeout.
>
> Lowering number of iterations would make the test condition
> less accurate as it's based on global counter.
>
> Instead, calculate the rate of iterations system can do in
> first 5 seconds and used that to decide whether to continue
> to run the test. If the rate is too slow, TCONF after 5
> seconds.
>

Generally, this method looks good, but maybe better to limit this
check_progress() only perform on -debug kernel?  Otherwise,

Reviewed-by: Li Wang <liwang@redhat.com>


======= FYI ==========
I'm seeking a fair way to make a global evaluation of the test
system to reset timeout dynamically for the whole LTP.

My original design thoughts:

  Create the numbers of threads equal to CPUs and bind them to
  the corresponding cpu for running. Use mutex lock to sync up
  each thread launch at the same time to collect the basic data
  for their CPU. Then we can compare the CPU state under the idle or
  busy time to get a relatively stationary _value_ to measure the system
  performance.

But so far the test method is not stable&reliable as expected.

  // do float computing + dirty 10*pagesz memory  in a limited times
  one_unit_of_operation();

  // count the CPU looping numbers with (type = idel, calcu)
  // and call one_unit_opertaion() in 1 sec
  cpu_1sec_looping(int type);

  idlespeed_loops = cpu_1sec_looping(idel);
  calculate_loops = cpu_1sec_looping(calcu);
  ...
  // count the _value_ from all CPU average loops
  ratio = calculate_avg / idealspeed_avg;

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220222/81c6241e/attachment.htm>