Hi,

On 10/30/2014 05:04 PM, Cyril Hrubis wrote:
> Hi!
>>   #define _GNU_SOURCE
>> @@ -30,9 +33,11 @@
>>   #include <stdlib.h>
>>   #include <sched.h>
>>   #include <sys/time.h>
>> +#include <sys/resource.h>
>>   #include <pthread.h>
>>   #include <sys/types.h>
>>   #include <sys/stat.h>
>> +#include <unistd.h>
>>   #include <fcntl.h>
>>   
>>   #include "test.h"
>> @@ -54,6 +59,8 @@ const char setspeed[]      = SYSFS_CPU_DIR 
>> "cpu0/cpufreq/scaling_setspeed";
>>   const char curspeed[]      = SYSFS_CPU_DIR "cpu0/cpufreq/cpuinfo_cur_freq";
>>   const char maxspeed[]      = SYSFS_CPU_DIR "cpu0/cpufreq/scaling_max_freq";
>>   
>> +const int units = 1000000; /* Mhz */
>> +
>>   static void cleanup(void)
>>   {
>>      SAFE_FILE_PRINTF(NULL, boost, "%d", boost_value);
>> @@ -110,26 +117,34 @@ void *thread_fn(void *val)
>>   {
>>      struct timeval tv_start;
>>      struct timeval tv_end;
>> -    int i, res = 0;
>> -    intptr_t timeout = (intptr_t) val;
>> +    int i;
>> +    unsigned long long res = 0;
> The res should be marked as volatile to avoid misoptimizations.
>
>> +    intptr_t timeout = (intptr_t) val, ret;
>> +
>> +    struct sched_param params;
>> +    params.sched_priority = sched_get_priority_max(SCHED_FIFO);
>> +    if (pthread_setschedparam(pthread_self(), SCHED_FIFO, &params)) {
>> +            tst_resm(TWARN | TERRNO,
>> +                    "failed to set FIFO sched with max priority");
>> +    }
>>   
>>      gettimeofday(&tv_start, NULL);
> We should use CLOCK_MONOTONIC_RAW for measuring the time here to avoid
> failures when ntp daemon changes the system time, etc.
>
>>      tst_resm(TINFO, "load CPU0 for %ld sec...", timeout);
>>   
>>      do {
>> -            for (i = 1; i < 10000; ++i)
>> -                    res += i * i;
>> +            for (i = 0; i < units; ++i)
>> +                    ++res;
> Hmm, are you sure that the number stored in res divided by units and
> timeout really yields the CPU speed?

It's rough calculation, can be close to CPU speed (if certain conditions 
apply),  but for comparison purposes it may fit.

> I guess that it may, but that would also depend on what compiler does
> with the code and how microcode is implemented in the target CPU, etc.
> Or are you 100% sure that res/units/timeout will yield cpu speed in Mhz
> in all cases?

No.

> If I'm reading the patch right, what it now does it two measurements to
> see if things are faster with boost, that is fine but we should rather
> stop calling the number speed and stop pretending that it's cpu speed in
> Mhz.

You are right, that's why I changed cpu freq to 'avg counter frequency'.

Thanks,
Alexey


------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to