On Wed, 28 Nov 2007, Peter W. Morreale wrote: > 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. > > I'm directing this question to you, however it may be of interest to the > community as well... > > I've been looking closely at the rtmutex code, spin locks in particular, > and noticed something that has me confused. I instrumented the code to > add some simple counters and have found that for non-rt loads, we seem > to perform priority boosts more frequently than expected. Here are some > numbers... > > rs_pi_boost = 2060 > rs_pi_unboost = 1451 > rs_rt_contention = 708 > > 'rs_pi_boost' and 'rs_pi_unboost' are are counts of the number of times > a task priority is about to be changed in __rt_mutext_adjust_prio(). > 'rs_rt_contention' is a count of the number of times an RT-priority task > entered task_blocks_on_rt_mutex() (which means the lock was outstanding > at that time the counter was incremented) > > I'm confused on two counts, 1) the disparity between the boost and > unboost, and 2) the factor of 2x difference between the (potentially) > about to block RT task and the boost counts. As was explained by Luis(sp? my fonts dont display that "i" part) you can be boosted multiple times and unboosted once. > > 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. > > The samples were taken after a reboot followed by a 'make' in an already > built kernel tree. The counts (gradually) grow in this proportion as > time/load passes. They are currently low due to the reboot. > > What got me started on this path was noticing the context switch counts > go extremely high with the addition of a single process. Here is the > output of a silly little program I wrote that reads /proc/stat and calcs > context-switches/second: > > prev: 1990167, current: 1992750, diff: 516/s > prev: 1992755, current: 1994567, diff: 362/s > prev: 1994569, current: 1997847, diff: 655/s > prev: 1997849, current: 2011904, diff: 2811/s # make start > prev: 2011913, current: 2041192, diff: 5855/s > prev: 2041194, current: 2074749, diff: 6711/s > prev: 2074752, current: 2107060, diff: 6461/s > prev: 2107065, current: 2139376, diff: 6462/s > prev: 2139378, current: 2164268, diff: 4978/s # make killed > prev: 2164274, current: 2166674, diff: 480/s > prev: 2166676, current: 2168187, diff: 302/s > prev: 2168189, current: 2169576, diff: 277/s > > Factor of 10x for a single make (no -j) on an otherwise idle system. > Again, this was on an already built kernel tree and taken shortly after > the a previous make invocation (implying the caches should be warm). > Since I'm hitting on the dcache and inode spin locks (that are now > rt_spin_locks) and only contending with other system processes (syslog, > etc) I'm at a loss attempting to understand why the dramatic increase in > the context switch rate. 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 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
