Re: [PATCH v2] sched/fair: Age the average idle time

[Phil Auld]

On Thu, Jun 17, 2021 at 04:40:06PM +0100 Mel Gorman wrote:
> On Thu, Jun 17, 2021 at 11:01:16AM -0400, Phil Auld wrote:
> > > Thanks, so far no serious objection :)
> > > 
> > > The latest results as I see them have been copied to
> > > https://beta.suse.com/private/mgorman/melt/v5.13-rc5/3-perf-test/sched/sched-avgidle-v1r6/html/dashboard.html
> > > They will move from here if the patch is accepted to 5-assembly replacing
> > > 3-perf-test. This naming is part of my workflow for evaluating topic
> > > branches separetly and then putting them together for another round
> > > of testing.
> > > 
> > > NAS shows small differences but NAS would see limited impact from the
> > > patch. Specjbb shows small losses and some minor gains which is unfortunate
> > > but the workload tends to see small gains and losses all the time.
> > > redis is a mixed bag but has some wins. hackbench is the main benefit
> > > because it's wakeup intensive and tends to overload machines where deep
> > > searches hurt.
> > > 
> > > There are other results in there if you feel like digging around
> > > such as sched-core tested with no processes getting tagged with prctl
> > > https://beta.suse.com/private/mgorman/melt/v5.13-rc5/5-assembly/sched/sched-schedcore-v1r2/html/dashboard.html
> > >
> > 
> > Thanks for the links. It's cool to see what your results dashboard looks like.
> > It's really small, what are you plotting in those heat maps?
> > 
> > It's hard for me to publish the results that come from our testing (web based
> > on intranet) but we don't see any major differences with this patch.  There
> > are some gains here and there mostly balanced by some loses.  Overall it comes
> > out basically as a wash across our main performance test workload.
> > 
> 
> Ok, that's unfortunate. It's also somewhat surprising but then again, I
> don't know what tests were executed.

Yes, I know, sorry. I get these really nice reports but they're hard to
summarize in text :)

The testing consists of NAS (mostly C, some D), stress-ng, libmicro, linpack
and stream, specjvm2008, specjbb2005 and a few others across a range of (x86_64)
hardware. 

>From libmicro there was these 2 which stand out

exit_100 	     52584      66975 [  -27.4%]
exit_100_nolibc      46831      57395 [  -22.6%]

Then some scattered gain and loss in the under +/-10% range.
That's on a 2-node Rome.  It's a bit worse on a 8-node Rome
but with libmicro it's a few nsecs here or there.


Here are some pieces from the summary page I pulled out and trimmed as an example:
kernel                            testcase              system           top % change
5.13.0_rc5.idle_aging    NASParallel-2_NUMA_nodes      gold-2s-b       NASParallel_ua_C_x: 4%
                                                                       NASParallel_sp_C_x: -4%
	
5.13.0_rc5.idle_aging    NASParallel-2_NUMA_nodes      amd-epyc2-rome  NASParallel_sp_C_x: 6%
					    			       NASParallel_sp_C_x: -10%
	
5.13.0_rc5.idle_aging    LinpackAndStream-2_NUMA_nod…  amd-epyc2-rome  Linpack_stream_default: 4%
							      	       Linpack_linpackd_default: -11%
	
5.13.0_rc5.idle_aging    LinpackAndStream-2_NUMA_nod…  gold-2s-b       Linpack_linpacks_default: 7%
                                                                       Linpack_linpackd_default: -2%

5.13.0_rc5.idle_aging    stress-ng-1_NUMA_nodes        gold-1s         STRESSngTest_getdent: 11%
							      	       STRESSngTest_madvise: -15%

5.13.0_rc5.idle_aging    Intel_Linpack-8_NUMA_nodes    gold-4s-b       IntelLinpack_default: 12%
							      	       IntelLinpack_single: -12%

The "gold"s are Intel based.

As I said, the perf team reported no real difference one way or the other.
>From their perspective this patch is basically neutral.

> 
> > It'll be interesting to see if it effects a sensitive, proprietary perf test
> > suite from a European company with a 3 letter name :)
> > 
> 
> I don't think it's worth the effort if it's failing microbenchmarks at
> the moment.

Fair enough. I'm sensitive to this one because it can be a real pain to track down minor
trade-off differences. And I believe you have been there too...


Cheers,
Phil

> 
> -- 
> Mel Gorman
> SUSE Labs
> 

--