[lkml]   [2004]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
On Saturday, August 21, 2004 4:24 pm, William Lee Irwin III wrote:
> 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.

Sorry, I should have been clearer, I was only disagreeing with the last part:
"There is also precisely zero relevance the benchmark has to anything real
users would do." Making kernbench run fast isn't a priority, but making sure
it doesn't run slow and hurt other apps is important, so in that sense it's a
useful benchmark, even if we're just using it as a load like you say above.

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

Huh? I guess booting on a machine this big is something of a stress test. :)

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

Yep, me too (though kernbench *is* frighteningly easy to setup and run :).

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

Ok, thanks.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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