Re: commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

From: Dario Faggioli
Date: Thu Oct 23 2008 - 04:39:43 EST

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 have had a "wa" time of 48-50% based on top or vmstat 1 100(last column heading, on the right).
> After applying kernel 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...

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.
- 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?


<<This happens because I choose it to happen!>>
(Raistlin Majere, DragonLance Chronicles -Dragons of Spring Drawning-)
Dario Faggioli
GNU/Linux Registered User: #340657
SIP Account: dario.faggioli@xxxxxxxxxxxxxxxxx or
Jabber Account: dario.faggioli@xxxxxxxxxx/WengoPhone
GnuPG Key ID: 4DC83AC4
GnuPG Key Fingerprint: 2A78 AD5D B9CF A082 0836 08AD 9385 DA04 4DC8 3AC4

Attachment: signature.asc
Description: This is a digitally signed message part