Re: 2.6.8.1-mm3

[William Lee Irwin III <wli@holomorphy.com>]

On Friday, August 20, 2004 4:02 pm, William Lee Irwin III wrote:
>> Parallel compilation is an extremely poor benchmark in general, as the
>> workload is incapable of being effectively scaled to system sizes, the
>> linking phase is inherently unparallelizable and the compilation phase
>> too parallelizable to actually stress anything. There is also precisely
>> zero relevance the benchmark has to anything real users would do.

On Sat, Aug 21, 2004 at 03:59:41PM -0400, Jesse Barnes wrote:
> I disagree.  Although I wouldn't expect to try and optimize the system for a 
> 'make -j 2048', it's important that things not suck when several users do 
> 'make -j 16' since that *is* a very common operation on machines like this 
> (though hopefully the runtime is dominated not by compiles but by actual 
> application runs).

Yet this criterion involves no performance metric; if it were a
benchmark it would quantify performance in a meaningful, reproducible,
and cross-system comparable way. AFAICT it's just being used as a
stress test for the dcache RCU issue.


On Friday, August 20, 2004 4:02 pm, William Lee Irwin III wrote:
>> It sounds like good news to me. The fact we boot at all instead
>> of spinning in perpetuity on spinlocks in interrupt context is
>> very good news to me, with a large added bonus of actually making
>> forward progress on workloads hitting global locks we've taken
>> steps to mitigate the locking overhead of.

On Sat, Aug 21, 2004 at 03:59:41PM -0400, Jesse Barnes wrote:
> Yep, I'm very excited about this.  It makes working with such systems to 
> improve other things infinitely easier (i.e. possible).

Stress test again...


On Friday, August 20, 2004 4:02 pm, William Lee Irwin III wrote:
>> I suppose the unfortunate thing is that we didn't discover anything
>> new at all, apart from quantifying certain things, e.g. how effective
>> the RCU improvements have been. IIRC that question was unanswered after
>> the last round, apart from (maybe) that things stopped livelocking.

On Sat, Aug 21, 2004 at 03:59:41PM -0400, Jesse Barnes wrote:
> Well, this isn't a very good benchmark for discovering things that we don't 
> already know (e.g. dcache and RCU issues).  Now that things appear to be 
> working however, we can start doing more realistic benchmarks.

I'll be happy to see those happen instead of kernel compiles. =)


On Friday, August 20, 2004 4:02 pm, William Lee Irwin III wrote:
>> I suppose another way to answer the question of what's going on is to
>> fiddle with ia64's implementation of profile_pc(). I suspect something
>> like this may reveal the offending codepaths.

On Sat, Aug 21, 2004 at 03:59:41PM -0400, Jesse Barnes wrote:
> Looks interesting.  I'll see if it works next week.

I can take it for a spin here to make sure it does the right thing.


-- wli