An error occurred fetching the project authors.
- 11 Oct, 2003 1 commit
-
-
Venkatesh Pallipadi authored
There is a bug in cpufreq call back funtion in timer_tsc routines, that can result in system deadlock. The issue is: grabbing the write_lock on xtime_lock without disabling the interrupts. So,=20 if we happen to get a timer interrupt while we are in this code, system will go into a deadlock. This bug only effects the kernels that have CONFIG_CPU_FREQ enabled.
-
- 21 Sep, 2003 1 commit
-
-
Andrew Morton authored
From: Ingo Molnar <mingo@elte.hu> the attached scheduler patch (against test2-mm2) adds the scheduling infrastructure items discussed on lkml. I got good feedback - and while i dont expect it to solve all problems, it does solve a number of bad ones: - test_starve.c code from David Mosberger - thud.c making the system unusuable due to unfairness - fair/accurate sleep average based on a finegrained clock - audio skipping way too easily other changes in sched-test2-mm2-A3: - ia64 sched_clock() code, from David Mosberger. - migration thread startup without relying on implicit scheduling behavior. While the current 2.6 code is correct (due to the cpu-up code adding CPUs one by one), but it's also fragile - and this code cannot be carried over into the 2.4 backports. So adding this method would clean up the startup and would make it easier to have 2.4 backports. and here's the original changelog for the scheduler changes: - cycle accuracy (nanosec resolution) timekeeping within the scheduler. This fixes a number of audio artifacts (skipping) i've reproduced. I dont think we can get away without going cycle accuracy - reading the cycle counter adds some overhead, but it's acceptable. The first nanosec-accuracy patch was done by Mike Galbraith - this patch is different but similar in nature. I went further in also changing the sleep_avg to be of nanosec resolution. - more finegrained timeslices: there's now a timeslice 'sub unit' of 50 usecs (TIMESLICE_GRANULARITY) - CPU hogs on the same priority level will roundrobin with this unit. This change is intended to make gaming latencies shorter. - include scheduling latency in sleep bonus calculation. This change extends the sleep-average calculation to the period of time a task spends on the runqueue but doesnt get scheduled yet, right after wakeup. Note that tasks that were preempted (ie. not woken up) and are still on the runqueue do not get this benefit. This change closes one of the last hole in the dynamic priority estimation, it should result in interactive tasks getting more priority under heavy load. This change also fixes the test-starve.c testcase from David Mosberger. The TSC-based scheduler clock is disabled on ia32 NUMA platforms. (ie. platforms that have unsynched TSC for sure.) Those platforms should provide the proper code to rely on the TSC in a global way. (no such infrastructure exists at the moment - the monotonic TSC-based clock doesnt deal with TSC offsets either, as far as i can tell.)
-
- 16 Sep, 2003 1 commit
-
-
Stephen Hemminger authored
Monotonic clock code uses reader/writer lock which is prone to same starvation problems as we saw with xtime. This patch changes it to seq_lock which is faster and won't starve writers in face of lots of readers.
-
- 09 Sep, 2003 2 commits
-
-
Andrew Morton authored
From: Dmitry Torokhov <dtor_core@ameritech.net> I noticed that although timer_tsc registers cpufreq notifier to detect frequency changes and adjust cpu_khz it does not set cyc2ns_scale.
-
Andrew Morton authored
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> CONFIG_TIMER_CYCLONE doesn't build at present because calibrate_tsc() was made static. The patch fixes that up and moves all calibrate_tsc functions into a common file, avoiding the current code duplication.
-
- 31 Aug, 2003 1 commit
-
-
Andrew Morton authored
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> All changes required to support timer services (gettimeofday) with HPET.
-
- 18 Aug, 2003 1 commit
-
-
Hollis Blanchard authored
Kernul proggrammers cant spel.
-
- 03 Jul, 2003 1 commit
-
-
John Stultz authored
This patch fixes a bad declaration of jiffies in timer_tsc.c and timer_cyclone.c, replacing it with the proper usage of jiffies.h. Caught by gregkh.
-
- 02 Jul, 2003 2 commits
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> This patch catches a corner case in the lost-tick compensation code. There is a check to see if we overflowed between reads of the two time sources, however should the high res time source be slightly slower then what we calibrated, its possible to trigger this code when no ticks have been lost. This patch adds an extra check to insure we have seen more then one tick before we check for this overflow. This seems to resolve the remaining "time doubling" issues that I've seen reported.
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> The patch tries to resolve issues caused by running the TSC based lost tick compensation code on CPUs that change frequency (speedstep, etc). Should the CPU be in slow mode when calibrate_tsc() executes, the kernel will assume we have so many cycles per tick. Later when the cpu speeds up, the kernel will start noting that too many cycles have past since the last interrupt. Since this can occasionally happen, the lost tick compensation code then tries to fix this by incrementing jiffies. Thus every tick we end up incrementing jiffies many times, causing timers to expire too quickly and time to rush ahead. This patch detects when there has been 100 consecutive interrupts where we had to compensate for lost ticks. If this occurs, we spit out a warning and fall back to using the PIT as a time source. I've tested this on my speedstep enabled laptop with success, and others laptop users seeing this problem have reported it works for them. Also to ensure we don't fall back to the slower PIT too quickly, I tested the code on a system I have that looses ~30 ticks about every second and it can still manage to use the TSC as a good time source. This solves most of the "time doubling" problems seen on laptops. Additionally this revision has been modified to use the cleanups made in rename-timer_A1.
-
- 30 Apr, 2003 1 commit
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> - Whitespace fixes - Fix for the case where HZ != 1000 (pointed out by Mika Penttila).
-
- 20 Apr, 2003 1 commit
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> This patch fixes a race in the timer_interrupt code caused by detect_lost_tick(). Since we're doing lost-tick compensation outside timer->mark_offset, time can pass between time-source reads which can cause gettimeofday inconsistencies. Additionally detect_lost_tick() was broken for the PIT case, since the whole point of detect_lost_tick() is to interpolate between two time sources to find inconsistencies. Additionally this could cause xtime_lock seq_lock reader starvation which has been causing machine hangs for SMP boxes that use the PIT as a time source. This patch fixes the described race by removing detect_lost_tick() and instead implementing the lost tick detection code inside mark_offset(). Some of the divs and mods being added here might concern folks, but by not calling timer->get_offset() in detect_lost_tick() we eliminate much of the same math. I did some simple cycle counting and the new code comes out on average equivalent or faster.
-
- 17 Apr, 2003 1 commit
-
-
Alan Cox authored
-
- 03 Apr, 2003 1 commit
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> This patch, written with the advice of Joel Becker, addresses a problem with the hangcheck-timer. The basic problem is that the hangcheck-timer code (Required for Oracle) needs a accurate hard clock which can be used to detect OS stalls (due to udelay() or pci bus hangs) that would cause system time to skew (its sort of a sanity check that insures the system's notion of time is accurate). However, currently they are using get_cycles() to fetch the cpu's TSC register, thus this does not work on systems w/o a synced TSC. As suggested by Andi Kleen (see thread here: http://www.uwsg.iu.edu/hypermail/linux/kernel/0302.0/1234.html ) I've worked with Joel and others to implement the monotonic_clock() interface. Some of the major considerations made when writing this patch were o Needs to be able to return accurate time in the absence of multiple timer interrupts o Needs to be abstracted out from the hardware o Avoids impacting gettimeofday() performance This interface returns a unsigned long long representing the number of nanoseconds that has passed since time_init().
-
- 28 Mar, 2003 1 commit
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> This patch allows one to manually specify the i386 gettimeofday time-source by passing clock=[pit|tsc|cyclone|...] as a boot argument. The argument will override the default probled selection, and in case the selected time-source not be avalible the code defaults to using the PIT (printing a warning saying so).
-
- 20 Mar, 2003 1 commit
-
-
Andrew Morton authored
From: Stephen Hemminger <shemminger@osdl.org> The CPU frequency change detection code can change the values used to compute time of day with TSC; but there was no locking around it.
-
- 02 Mar, 2003 1 commit
-
-
Andrew Morton authored
Patch from: john stultz <johnstul@us.ibm.com> The kernel will currently panic if it was built with CONFIG_X86_TSC and someone boots it with `notsc'. Change it to just print a warning.
-
- 25 Feb, 2003 1 commit
-
-
Michael Hayes authored
doesnt -> doesn't (35 occurrences)
-
- 13 Feb, 2003 2 commits
-
-
Andrew Morton authored
Patch from: john stultz <johnstul@us.ibm.com> This patch "fixes" the timer_cyclone code by having it initialize fast_gettimeoffset_quotient and cpu_khz in the same manner as timer_tsc. This is required for enabling the timer_cyclone code on the x440. Ideally fast_gettimeoffset_quotient would not be used outside timer_tsc and cpu_khz would be initialized generically outside the timer subsystem. I have patches to do this, but they touch quite a bit of generic code, and I'd rather not make the timer_cyclone enablement (patch to follow) depend on these larger changes.
-
Andrew Morton authored
Patch from: john stultz <johnstul@us.ibm.com> This cleanup patch makes fast_gettimeoffset_quotient (a timer_tsc specific variable) static, and replaces its usage with cpu_khz, making it timer_opt independent.
-
- 13 Jan, 2003 1 commit
-
-
John Stultz authored
This cleans up the delay code by moving the timer-specific implementations into the timer_ops struct. Thus, rather then doing: if(x86_delay_tsc) __rdtsc_delay(loops); else if(x86_delay_cyclone) __cyclone_delay(loops); else if(whatever.... we just simply do: timer->delay(loops); Making it much easier to accommodate alternate time sources.
-
- 06 Jan, 2003 1 commit
-
-
Dominik Brodowski authored
- global loops_per_jiffy, x86 cpu_khz and x86 fast_gettimeoffset_quotient can only be safely adjusted on UP - x86 per-CPU loops_per_jiffy does not depend on TSC - save reference values so that rounding errors do not accumulate
-
- 28 Dec, 2002 1 commit
-
-
James Bottomley authored
Also localises the parameters and setup into kernel/timers Adds an external flag so that the tsc can be disabled from the machine specific setup (used by voyager)
-
- 11 Nov, 2002 1 commit
-
-
Art Haas authored
-
- 05 Nov, 2002 1 commit
-
-
Alan Cox authored
This is used by the following Cyrix patch to handle buggy or spec tight PIT stuff
-
- 12 Oct, 2002 1 commit
-
-
Adrian Bunk authored
The timer-handling split patch moved cpufreq stuff from time.c to timers/timer_tsc.c but not the corresponding #include <linux/cpufreq.h> causing the build to fail. The fix is simple.
-
- 10 Oct, 2002 3 commits
-
-
Greg Kroah-Hartman authored
Here's an additional patch that contains the cleanups I did to John's timer patches. It does the following: - uses C99 initializers - makes the timer list static - adds better documentation to the timer function structure - makes the timer init function return 0 on success - NULL terminates the list of timers to make further patches easier.
-
John Stultz authored
This is the final part 3 of 3 of my timer-change patch. Part 3 integrates the moved code (from part 2) into the new infrastructure (from part 1).
-
John Stultz authored
This is part 2 of 3 of my timer-change patch. Part 2 is just a bulk move of code out of time.c and into timer_pit.c and timer_tsc.c. No code is changed, only moved. Please note, this code will not compile without the final third part of this patch collection. This was done for readability alone.
-