Subject: Re: [patch 13/19] GTOD: Mark TSC unusable for highres timers
Newsgroups: gmane.linux.kernel
Date: 2006-11-10 10:35:58 GMT (2 years, 33 weeks, 6 days, 3 hours and 16 minutes ago)
> We're limping along in a semi-OK fashion with the TSC. that's because we fake it a heck of a lot; like after C3 we just make the kernel guestimate how much to progress it so that it has just enough ductape on it to not totally fall apart ;( There's no easy answer. We can keep trying to ductape the TSC everywhere it sort of breaks (cpu frequency changes on older chips, C3 idle (which old kernels hit less often just because of the constant timer ticks), cross cpu drifts and offsets etc etc). What that would need at minimum is 1) a per cpu "offset" that gets added to whatever we read from rdtsc instruction 2) a per cpu "multiplier" or something that gets applied to tsc deltas 3) all code that gets to mop up where TSC breaks (cpuspeed and C3 power states) use "other timers" to adjust the offset/multiplier values on a per cpu basis, rather than "hardware TSC". I suspect that is enough to mostly keep it limping along. It's not cheap, but it moves the costs mostly to the places where the hardware can't do it, so if you want to call gettimeofday() in a tight loop at least you don't pay the hpet tax. (only an add and maybe a mul but those are cheap and effectively unavoidable if we want to keep the illusion alive) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org