lkml.org 
[lkml]   [2004]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.8.1-mm3
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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.389 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site