[lkml]   [2004]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernbench on 512p
On Thu, Aug 19, 2004 at 08:16:10PM -0400, Jesse Barnes wrote:
> On Thursday, August 19, 2004 7:38 pm, Paul E. McKenney wrote:
> > > 41.4% 58.6% 0% rcu_state
> > > 61.3% 38.7% 0% __rcu_process_callbacks+0x260
> > > 41.4% 58.6% 0% rcu_check_quiescent_state+0xf0
> > >
> > > So it looks like the dcache lock is the biggest problem on this system
> > > with this load. And although the rcu stuff has improved tremendously for
> > > this system, it's still highly contended.
> >
> > Was this run using all of Manfred's RCU patches? If not, it would be
> > interesting to see what you get with full RCU_HUGE patchset.
> So that stuff isn't in What I tested was pretty close to a stock
> version of that tree. Where can I grab a version of that patchset that
> applies to a recent kernel?

If I am not too confused, you need #4 and #5 out of Manfred's set of
five RCU_HUGE patchset. They are at:

A little work will be required to get them to apply. For example, in
the first patch, instead of:


one would say:


due to the addition of the _bh() primitives. The "rcu_ctrlblk."
and "rcu_state." have been replaced by pointers in order to handle
multiple different types of grace periods:

o Traditional grace periods based on context switch, executing
in user mode, or running the idle loop.

o New-age low-latency grace periods based on running with
interrupts enabled.

Thanx, Paul
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.085 / U:5.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site