Re: rt mutex priority boost

On Wed, 2007-11-28 at 16:49 -0500, Steven Rostedt wrote:

On Wed, 28 Nov 2007, Peter W. Morreale wrote:

quoted

Steve,

Hi Peter,

I don't always read mailing lists every day, so if you want a quicker
response from me, it's best to CC me.

Will do.  didn't want to flood your mailbox, if that was the case... :-)

..

As was explained by Luis(sp? my fonts dont display that "i" part) you can
be boosted multiple times and unboosted once.

quoted

My expectation would be that all three counters would be more or less
the same.  Further, that we would only boost non-RT tasks in contention
with an RT task.  Is that a wrong assumption?  The code seems to imply
that we boost anyone.

Yes, we boost everyone!

IIRC, Ingo, Thomas, myself et al had a discussion about this. I think it
came down to boosting non-rt tasks would help normal scheduling as well.
That is, boosting lower tasks to help higher non-rt tasks can increase
reaction times for nice desktop user experiences.

Hummm... see below...

Well, make does do a lot af IO and syscalls. Accessing the hard drive.
This in turn will kick off interrupts and softirqs. Which will all contend
for spinlocks, and since they are all working together, expect a lot of
contention.

-- Steve

It does, and that was the point.  

Switching gears here a little bit...

The real problem I see is under a moderate 'dbench' load (No laughing,
you want VFS contention, use dbench :-) I can easily bump the cs/s
(context-switch/sec) rate to 380k/s.   

This on a ramfs (no disk involved) partition.  The bad part is that
top(1) reports 50-60% idle CPU time.  Which implies that 2 of my 4
x86_64 intels are spinning while there is work to do.  

As an early experiment, I converted the dcache, inode, and vfsmount
spins to raw, and performance jumped by 4x.  (I realized later that
dbench does alot of record locking and was still hammered by the BKL,
otherwise I suspect it would have been significantly greater...)  This
also reduced the cs/s rate to below 100k/s (from the high of ~380k/s)

It seems clear that a single point of contention (e.g: the dcache lock
in the above workload) greatly impacts the throughput of the hardware
platform.  There are similar points of contention with dev->_xmit_lock,
and queue_lock in the networking stack.   

Obviously, this is an issue for real-world apps.  Those pesky thingies
think they need data from various sources to do stuff.  That was humor. 

At the risk of being chastised, is (or has) this any discussion on this
been taking place?  

Thx,
-PWM

-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html