Greetings Folks,

In order to explore why SCHED_RR tasks are being delayed under load on my 
box, I added some debug code to semaphores (knew it was proc for [RR] 
vmstat, but what about others?).  At the moment, normal semaphores only 
record the fact that they have been downed in the owner's task 
struct.  rw_semaphores, however,  also have some timeout code (lib/rwsem.c) 
to find out _who_ is holding the semaphore for so long.  In 
scheduler_tick(), I print out stats as to how many expires/second, along 
with the number of tasks which were expired while holding a semaphore.  See 
the attached logs... the numbers seems _awfully_ high to me, and if I 
prevent expiration of these guys, most of my SCHED_RR vmstat/top stalls 
just go away.

I'm wondering if it's worth while adding the wrappers and starvation 
timeout code to normal semaphores (hmm, what about spinlocks... we do have 
a might_sleep check which amounts to the same thing if you send any lock 
holder off to the expired land when there are interactive tasks doing round 
robin) to see if anybody starves for these.  The same random thoughts occur 
for yield() for normal tasks, though I've yet to trigger a printk there.

Anyway, logs attached in case they might be of interest.

	-Mike

P.S. logs are from 67-mm4 in case anyone looks up line numbers and 
wonders.  There are no twiddlings from yours truely other than the 
semaphore stuff... it's virgin code, no wild/crazy/stupid experiments ;-)