lkml.org 
[lkml]   [2002]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] tsc-disable_B9
From
Date
> certainly fair enough argument in theory, but in practice you're not
> going to risk running those apps in a laptop or in general with any
> power management that will decrease the frequency of the cpu anytime.

Any PIII with speedstep, any Athlon and PIV.

> Furthmore the speedstep right now today can crash any laptop that boots
> at reduced mhz and that switches to higher mhz at runtime, that change

Actually the reduced loops in the kernel seem to work fine

> of the tsc frequency simply make udelay run faster, and it'll break
> drivers easily. I suspect there's even an unfixable race condition in
> the speedstep hardware since it's not the kernel asking for the change

Fixed in the -ac tree for the non APM triggered case because we use
cpufreq code

> significant info via the tsc to userspace, and there's no way to know
> that your app isn't breaking because of numa, unless you disable the tsc
> to userspace.

And you can test that with notsc. Oh and you might also want the code
that makes notsc on a tsc only kernel print a warning btw. badtsc lets
you say "I have a brain cell" notsc lets you select "clueless app
checking mode"


As to the other issue. As soon as we have plug in tsc handling that can
use ACPI, x86-64, summit and other timer sources I'm very keen to put
the tsc based timer in as a fallback before the PIT, and to do chip
sanity checks on it (matching clockmul, not spudstop etc)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.082 / U:1.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site