[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1bd3bb9c-581e-2e18-aa41-ecf000e3686e@meta.com>
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
Powered by blists - more mailing lists