Re: schbench v1.0

[Chris Mason <clm@meta.com>]

On 4/20/23 11:05 AM, Peter Zijlstra wrote:
> On Mon, Apr 17, 2023 at 10:10:25AM +0200, Chris Mason wrote:
> 
>> F128 N10                EEVDF    Linus
>> Wakeup  (usec): 99.0th: 755      1,266
>> Request (usec): 99.0th: 25,632   22,304
>> RPS    (count): 50.0th: 4,280    4,376
>>
>> F128 N10 no-locking     EEVDF    Linus
>> Wakeup  (usec): 99.0th: 823      1,118
>> Request (usec): 99.0th: 17,184   14,192
>> RPS    (count): 50.0th: 4,440    4,456
> 
> With the below fixlet (against queue/sched/eevdf) on my measly IVB-EP
> (2*10*2):
> 
> ./schbench -F128 -n10 -C
> 
> Request Latencies percentiles (usec) runtime 30 (s) (153800 total samples)
> 	  90.0th: 6376       (35699 samples)
> 	* 99.0th: 6440       (9055 samples)
> 	  99.9th: 7048       (1345 samples)
> 
> CFS
> 
> schbench -m2 -F128 -n10	-r90	OTHER	BATCH
> Wakeup  (usec): 99.0th:		6600	6328
> Request (usec): 99.0th:		35904	14640
> RPS    (count): 50.0th:		5368	6104
> 

Peter and I went back and forth a bit and now schbench git has a few fixes:

- README.md updated

- warmup time defaults to zero (disabling warmup).  This was causing the
stats inconsistency Peter noticed below.

- RPS calculated more often.  Every second instead of every reporting
interval.

- thread count scaled to CPU count when -m is used.  The thread count is
per messenge thread, so when you use -m2 like Peter did in these runs,
he was ending up with 2xNUM_CPUs workers.  That's why his wakeup
latencies are so high, he had double the work that I did.

I'll experiment with some of the suggestions he made too.

-chris