Re: [PATCH]O18.1int

[Nick Piggin <piggin@cyberone.com.au>]

Andrew Morton wrote:

>We have a problem.   See the this analysis from Steve Pratt.
>
>
>Steven Pratt <slpratt@austin.ibm.com> wrote:
>
>>Mark Peloquin wrote:
>>
>>
>>>Been awhile since results where posted, therefore this is a little long.
>>>
>>>
>>>Nightly Regression Summary for 2.6.0-test3 vs 2.6.0-test3-mm3
>>>
>>>Benchmark         Pass/Fail   Improvements   Regressions       
>>>Results       Results   Summary
>>>---------------   ---------   ------------   -----------   
>>>-----------   -----------   -------
>>>dbench.ext2           P            N              N        2.6.0-test3 
>>>2.6.0-test3-mm3    report
>>>dbench.ext3           P            N              Y        2.6.0-test3 
>>>2.6.0-test3-mm3    report 
>>>
>>The ext3 dbench regression is very significant for multi threaded 193 -> 
>>118.  Looks like this regression first showed up in mm1 and does not 
>>exist in any of the bk trees.
>>
>>http://ltcperf.ncsa.uiuc.edu/data/history-graphs/dbench.ext3.throughput.plot.16.png
>>
>>
>>>volanomark            P            N              Y        2.6.0-test3 
>>>2.6.0-test3-mm3    report
>>>
>>Volanomark is significant as well.  10% drop in mm tree. This one also 
>>appeared to show up in mm1 although it was a 14% drop then so mm3 
>>actually looks a little better.  There were build errors on mm2 run so I 
>>don't have that data at this time.
>>Following link illustrates the drop in mm tree for volanomark.
>>
>>http://ltcperf.ncsa.uiuc.edu/data/history-graphs/volanomark.throughput.plot.1.png
>>
>>
>>SpecJBB2000 for high warehouses also took a bit hit.  Probably the same 
>>root cause as volanomark.
>>Here is the history plot for the 19 warehouse run.
>>
>>http://ltcperf.ncsa.uiuc.edu/data/history-graphs/specjbb.results.avg.plot.19.png
>>
>>Huge spike in idle time.
>>http://ltcperf.ncsa.uiuc.edu/data/history-graphs/specjbb.utilization.idle.avg.plot.19.png
>>
>>
>>>http://ltcperf.ncsa.uiuc.edu/data/2.6.0-test3-mm3/2.6.0-test3-vs-2.6.0-test3-mm3/ 
>>>
>>>
>
>Those graphs are woeful.
>

Aren't they.

>
>Steve has done some preliminary testing which indicates that the volanomark
>and specjbb regressions are due to the CPU scheduler changes.
>
>I have verifed that the ext3 regression is mostly due to setting
>PF_SYNCWRITE on kjournald.  I/O scheduler stuff.  I don't know why, but
>that patch obviously bites the dust.  There is still a 10-15% regression on
>dbench 16 on my 4x Xeon which is due to the CPU scheduler patches.
>

Thats fine. I never measured any improvement with it. Its sad that
that it didn't go as I hoped, but that probably tells you I don't
know enough about how journalling works.

>
>It's good that the reaim regression mostly went away, but it would be nice
>to know why.  When I was looking into the reaim problem it appeared that
>setting TIMESLICE_GRANULARITY to MAX_TIMESLICE made no difference, but more
>careful testing is needed on this.
>
>There really is no point in proceeding with this fine tuning activity when
>we have these large and not understood regressions floating about.
>

I think changes in the CPU scheduler cause butterflies to flap their
wings or what have you. Good luck pinning it down.

>
>I suggest that what we need to do is to await some more complete testing of
>the CPU scheduler patch alone from Steve and co.  If it is fully confirmed
>that the CPU scheduler changes are the culprit we need to either fix it or
>go back to square one and start again with more careful testing and a less
>ambitious set of changes.
>
>It could be that we're looking at some sort of tradeoff here, and we're
>already too far over to one side.  I don't know.
>
>It might help if you or a buddy could get set up with volanomark on an OSDL
>4-or-8-way so that you can more closely track the effect of your changes on
>such benchmarks.
>

I think you'd be wasting your time until the interactivity side of
things is working better. Unless Con has a smaller set of undisputed
improvements to test with.