Re: 2.6.8.1-mm3
From: William Lee Irwin III (wli_at_holomorphy.com)
Date: 08/21/04
- Previous message: David N. Welton: "Re: Linux Incompatibility List"
- In reply to: Jesse Barnes: "Re: 2.6.8.1-mm3"
- Next in thread: Jesse Barnes: "Re: 2.6.8.1-mm3"
- Reply: Jesse Barnes: "Re: 2.6.8.1-mm3"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 21 Aug 2004 13:24:35 -0700 To: Jesse Barnes <jbarnes@engr.sgi.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: David N. Welton: "Re: Linux Incompatibility List"
- In reply to: Jesse Barnes: "Re: 2.6.8.1-mm3"
- Next in thread: Jesse Barnes: "Re: 2.6.8.1-mm3"
- Reply: Jesse Barnes: "Re: 2.6.8.1-mm3"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
