Re: commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

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

Re: commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

[Dario Faggioli]

[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]

On Tue, 2008-10-21 at 08:55 -0500, Jonathan Johnson wrote:
> Hello all,
Hello again Jonathan,

>   sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
>     
>     commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream
> 
Ok, this is the patch that adds a rescheduling point when unthrottling
the root rt_rq, isn't it?

> 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.
>
Mmm... I see...

> THANK YOU
> 
Well, you're welcome... But... The problem is that I'm not sure I can
see how that patch could have solved (or lightened) the issue you are
reporting about I/O wait time.
It, in fact, is quite unrelated with I/O stuffs, actually! :-O

All I can think about is something like some kernel threads,
responsible, or somehow related to I/O, driver, RAID, etc., get
throttled and, when unthrottled back, they were not rescheduled as soon
as they can, as they are after the bugfix.
Anyway:
- I know the I/O layer too few to know if this is a possible scenario;
- I don't think the added latency the bug entailed to be so much severe,
  otherwise I think it would be noticed much before.

I'm very sorry, but my lack of knowledge of the details of the I/O
layer, prevents me from being more helpful than this. :-(

Maybe, if you have not already done it, you can bisect and run your
test. That way we can see if that commit is really the one that is
responsible for the performance improvement, can you?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>>
(Raistlin Majere, DragonLance Chronicles -Dragons of Spring Drawning-)
----------------------------------------------------------------------
Dario Faggioli
GNU/Linux Registered User: #340657
Web: http://www.linux.it/~raistlin
Blog: http://blog.linux.it/raistlin
SIP Account: dario.faggioli@sipproxy.wengo.fr or
             raistlin@ekiga.net
Jabber Account: dario.faggioli@jabber.org/WengoPhone
GnuPG Key ID: 4DC83AC4
GnuPG Key Fingerprint: 2A78 AD5D B9CF A082 0836 08AD 9385 DA04 4DC8 3AC4

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]