Re: [tbench regression fixes]: digging out smelly deadmen.
From: Rafael J. Wysocki <hidden>
Date: 2008-10-25 11:09:19
Also in:
lkml
On Saturday, 25 of October 2008, David Miller wrote:
From: "Rafael J. Wysocki" <redacted> Date: Sat, 25 Oct 2008 00:25:34 +0200quoted
On Friday, 10 of October 2008, Ingo Molnar wrote:quoted
* Evgeniy Polyakov [off-list ref] wrote:quoted
On Fri, Oct 10, 2008 at 01:42:45PM +0200, Ingo Molnar (mingo@elte.hu) wrote:quoted
quoted
vanilla 27: 347.222 no TSO/GSO: 357.331 no hrticks: 382.983 no balance: 389.802okay. The target is 470 MB/sec, right? (Assuming the workload is sane and 'fixing' it does not mean we have to schedule worse.)Well, that's where I started/stopped, so maybe we will even move further? :)that's the right attitude ;)Can anyone please tell me if there was any conclusion of this thread?I made some more analysis in private with Ingo and Peter Z. and found that the tbench decreases correlate pretty much directly with the ongoing increasing cpu cost of wake_up() and friends in the fair scheduler. The largest increase in computational cost of wakeups came in 2.6.27 when the hrtimer bits got added, it more than tripled the cost of a wakeup. In 2.6.28-rc1 the hrtimer feature has been disabled, but I think that should be backports into the 2.6.27-stable branch.
Thanks a lot for the info. Could you please give me a pointer to the commit disabling the hrtimer feature? Rafael