[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0904161539130.23632@qirst.com>
Date: Thu, 16 Apr 2009 15:53:09 -0400 (EDT)
From: Christoph Lameter <cl@...ux.com>
To: Ingo Molnar <mingo@...e.hu>
cc: linux-kernel@...r.kernel.org
Subject: Scheduler regression: Too frequent timer interrupts(?)
Since 2.6.22 the Linux scheduler interrupts programs with increasing
frequency. The interrupts cause run time variances that are affecting HPC
jobs. Various low latency jobs show increasing runtimes because of these
additional interrupts by the scheduler.
In the following test a simple program was run that continually retrieves
TSC and measures the times between the TSC retrievals. A run time variance
is noted whenever the time between two TSC retrievals is larger than 1
usec (on a 3.3Ghz Xeon box quad cores dual processor). The numbers given
are the interrupts occuring in a 10 second measurement period. The tests
can be downloaded from http://gentwo.org/ll .
Kernel Test 1 Test 2 Test 3 Variances(SUM)
2.6.22 383 540 667 1590
2.6.23 2738 2019 2303 7060
2.6.24 2503 573 583 3659
2.6.25 302 359 241 902
2.6.26 2503 2501 2503 7507
2.6.27 2502 2503 2478 7483
2.6.28 2502 2504 2502 7508
2.6.29 2502 2490 2503 7495
2.6.30-rc2 2504 2503 2502 7509
The kernel was compiled with high res timer support and a HZ of 250.
The 2.6.22 kernel has only about 38.3 disruptions per second. That likely
means that HRTIMER is able to eliminate the timer interrupt.
In .23 this is no longer possible and we get the full number of 250 timer
interrupts per second. Fixed again in .25 but .26 looses it again.
Can we restore the .22 situation where a running task without any
competitor on the same cpu does not need the timer interrupt?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists