Messages in this thread | | | Date | Fri, 21 Apr 2023 14:14:10 -0400 | Subject | Re: schbench v1.0 | From | Chris Mason <> |
| |
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
| |