Re: commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

[Jonathan Johnson]

Hello all,

  sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
    
    commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

Many previous kernels up to and include 2.6.27.1 have had a "wa" time of 48-50% based on top or vmstat 1 100(last column heading, on the right).
After applying kernel 2.6.27.2 the read "wa" time has dropped for reads down to 0%-10%.  After reading the changelog
I used the same .config for this kernel as several previous ones.
I figured it must be this commit that made the different, since there are only about 12 commits and this seem most likely.

THANK YOU

However,  the "wa" times remain at 40%-50%(50% maybe 100% of one CPU core and its a dual) for writing and/or output.  I don't know if there is a corresponding queue for writing or output,
 but it also needs examining.  I don't know how it related to reading from the hard drive either, but it was a dramatic improvement.  Given that all on my hardware is almost "top-of-the-line", I
don't believe my hardware is at fault for the high "wa"(waiting for data).

My write speed especially to my RAID 6 seems to get worse and worse.  I have all the same and supported hard drives.  My original array had 6 mismatched drives at 20-24mb/s write speed.
I replaced them with 4 1TB drives and now write speed is under 100k/s especially when tranmitting data to this computer over the network.

I know some C++, but have never debug a program on this scale, and don't even know how to start.  Any advice would be appreciated.


Later,
Jonathan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/