linux-kernel - Re: schbench v1.0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Apr 2023 14:14:10 -0400
From:   Chris Mason <clm@...a.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     David Vernet <void@...ifault.com>, linux-kernel@...r.kernel.org,
        kernel-team@...com, Ingo Molnar <mingo@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        gautham.shenoy@....com
Subject: Re: schbench v1.0

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