Re: schbench v1.0

[Chen Yu]

Hi Chris,

On 2023-04-21 at 14:14:10 -0400, Chris Mason wrote:
> 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.
> 

Sorry for popping up, while we are doing some eevdf tests and encountered
an issue using the latest schbench, we found this thread. It seems that
there is a minor corner case to be dealt with. Could you help take a look
if the following change make sense?

thanks,
Chenyu