linux-kernel - Re: commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1224751147.9835.40.camel@Palanthas>
Date:	Thu, 23 Oct 2008 10:39:07 +0200
From:	Dario Faggioli <raistlin@...ux.it>
To:	Jonathan Johnson <johnsonn@...c.edu>
Cc:	linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl,
	mingo@...e.hu, tglx@...utronix.de, trimarchimichael@...oo.it
Subject: Re: commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

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@...proxy.wengo.fr or
             raistlin@...ga.net
Jabber Account: dario.faggioli@...ber.org/WengoPhone
GnuPG Key ID: 4DC83AC4
GnuPG Key Fingerprint: 2A78 AD5D B9CF A082 0836 08AD 9385 DA04 4DC8 3AC4

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)