Re: 2.6.8.1-mm3

[Jesse Barnes]

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.

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).

> 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.

Yep, I'm very excited about this.  It makes working with such systems to 
improve other things infinitely easier (i.e. possible).

> 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.

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 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.

Looks interesting.  I'll see if it works next week.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/