Re: [PATCH rt-tests] queuelat: use ARM implementation of gettick also for all !x86 archs

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: "John Kacur" <jkacur@redhat.com>,
	"Uwe Kleine-König" <ukleinek@debian.org>,
	"Clark Williams" <williams@redhat.com>,
	"Linux RT Users" <linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH rt-tests] queuelat: use ARM implementation of gettick also for all !x86 archs
Date: Mon, 16 Dec 2019 16:34:49 +0100	[thread overview]
Message-ID: <20191216153449.sfxptmlyfthoianp@linutronix.de> (raw)
In-Reply-To: <20191213230256.GA20494@amt.cnet>

On 2019-12-13 21:02:56 [-0200], Marcelo Tosatti wrote:
> > > That freq. script reports here:
> > > |1555.184 1566.269 1566.498 1560.055 1593.149 1568.185 1583.807 1599.096 2574.546 2572.408 2573.849 2583.862 2619.402 1825.680 1847.264 1870.318 2552.102 1570.552 1589.650 1595.813 1590.253 1573.834 1589.438 1599.439 1770.963 1786.370 1814.918 1811.936 1828.277 1850.905 1861.976 1792.809
> > > 
> > > I guess I pick one…
> > > 
> > > Could someone please figure out the actual difference of clock_gettime()
> > > vs rdtsc() so we know how important it is. Based on its current
> > > implementation, if memmove() takes >1sec then it ends up undetected
> > > because only the ns of the timestamp are considered for.
> 
> /* Program parameters:
>  * max_queue_len: maximum latency allowed, in nanoseconds (int).
>  * cycles_per_packet: number of cycles to process one packet (int).
>  * mpps(million-packet-per-sec): million packets per second (float).
>  * tsc_freq_mhz: TSC frequency in MHz, as measured by TSC PIT
>  * calibration 
>  * (search for "Detected XXX MHz processor" in dmesg, and use the
>  * integer part).
>  */
> 
> So you have to pass it "processor frequency" (you can change the names, 
> its TSC but thats x86 specific). The script grabs the processor
> frequency (so you have to adjust that the script to ARM).
> 
> And thats it. Please replace tsc_mhz -> processor_freq.

So the script reports the freq. from 1555.184 Mhz to 2574.546 Mhz.
And I doubt the numbers remain steady on today's x86 even with
gov=performance.
However, I asked for the frequency to be used on !x86 given the code we
have. It was fixed in hurry and you would have to use 1000 so that the
math keeps working.
Then I asked how much benefit of this complicated TSC calculation vs
clock_gettime() has.
I tried to use it myself but after 30secs I saw no output, it just ate
100% and it seemed to do nothing. So I gave up.

Sebastian