Re: must-fix list for 2.6.0

[Dave Hansen]

Gerrit Huizenga wrote:
> Which affects JVM in most cases.  NPTL based JVMs will possibly
> obviate that problem.  My guess is that in the JVM case, they have
> a bad locking model (er, a simpler 2-tier locking model instead of
> a more correct and complex 3-tier locking model) for their threading
> operations.  As a result, they use either sched_yield() or used
> to use pause() to relinquish the processor so the world could change
> and they could acquire the locks they wanted.

The JVM's extensive use of sched_yield(), plus the HT scheduler causes
some pretty undesirable behaviour in SPECjbb(tm) (see disclaimer).  It
starves some pieces of the benchmark so badly, that the benchmark
results are invalid.  We also start to get tons of idle time as the load
goes up.

In case anybody is curious, we're trying to share more of the data that
we collect when we run the benchmarks.  Most of it us useless, but
someone might find a gem or two.  Here are two runs, one with HT, and
the other without.  There's also a pretty busy gnuplot graph in there:
http://www.sr71.net/prof/jbb/elm3a2/

The benchmark results can be found in:
<run-name>/benchmark/SPECjbb.*

Disclaimer:
SPEC (tm) and the benchmark name SPECjbb (tm) are registered trademarks
of the Standard Performance Evaluation Corporation. The benchmarking was
conducted for research purposes only and were non-compliant with the
following deviations from the rules:

  1. It was run on hardware that does not meet the SPEC
  availability-to-the public criteria. The machine was an
  engineering sample.

-- 
Dave Hansen
[e-mail]