Re: [PATCH][2.5] notsc option needs some attention/TLC

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Mikael Pettersson]

Zwane Mwaikambo writes:
 > notsc doesn't work on a box with a TSC, when we need need the option the 
 > most...
 > 
 > Index: linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c
 > ===================================================================
 > RCS file: /build/cvsroot/linux-2.5.46/arch/i386/kernel/cpu/common.c,v
 > retrieving revision 1.1.1.1
 > diff -u -r1.1.1.1 common.c
 > --- linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c	5 Nov 2002 01:47:31 -0000	1.1.1.1
 > +++ linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c	9 Nov 2002 03:10:45 -0000
 > @@ -12,6 +12,11 @@
 >  
 >  static int cachesize_override __initdata = -1;
 >  static int disable_x86_fxsr __initdata = 0;
 > +#ifdef CONFIG_X86_TSC
 > +static int tsc_disable __initdata = 0;
 > +#else
 > +#define tsc_disable	1
 > +#endif

CONFIG_X86_TSC means "I have a TSC, period" not "I may have a TSC".
It's an optimisation option, not a "try this" option.

If we configure for "I have a TSC, period" you add the option
to disable it, which nullifies any benefit of the config option
in the first place since we can't assume TSC presence any more.
If we don't configure for TSC, you force tsc_disable, which means
that a generic kernel _can't_ use the TSC.

People with broken TSCs need to run non-TSC-assuming kernels.

/Mikael

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Alan Cox]

On Sat, 2002-11-09 at 12:00, Mikael Pettersson wrote:
> If we configure for "I have a TSC, period" you add the option
> to disable it, which nullifies any benefit of the config option
> in the first place since we can't assume TSC presence any more.
> If we don't configure for TSC, you force tsc_disable, which means
> that a generic kernel _can't_ use the TSC.

2.4 was modified to printk a message that TSC was not disabled. This
does confuse people

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Martin J. Bligh]

>> If we configure for "I have a TSC, period" you add the option
>> to disable it, which nullifies any benefit of the config option
>> in the first place since we can't assume TSC presence any more.
>> If we don't configure for TSC, you force tsc_disable, which means
>> that a generic kernel _can't_ use the TSC.
> 
> 2.4 was modified to printk a message that TSC was not disabled. This
> does confuse people

Having this config option ass-backwards is mind-bogglingly confusing,
and there seems no real reason for it. John had a plan to just put 
in CONFIG_X86_PIT instead as the inverse of this, and delete 
CONFIG_X86_TSC. He seems to have gone off this idea for some reason
I can't understand ... I think it solves a lot of these issues ...

Having a config option called TSC that in fact has nothing to directly
do with the TSC, but disables the PIT seems silly. The first time I
read all this code I spend quite a while thinking it was all the 
incorrect, and the wrong way around ... things should be more intuitive
than that.

M.

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Zwane Mwaikambo]

On 9 Nov 2002, Alan Cox wrote:

> On Sat, 2002-11-09 at 12:00, Mikael Pettersson wrote:
> > If we configure for "I have a TSC, period" you add the option
> > to disable it, which nullifies any benefit of the config option
> > in the first place since we can't assume TSC presence any more.
> > If we don't configure for TSC, you force tsc_disable, which means
> > that a generic kernel _can't_ use the TSC.
> 
> 2.4 was modified to printk a message that TSC was not disabled. This
> does confuse people

This is all very confusing, notsc isnn't supposed to work with cpus with 
TSCs?

	Zwane
-- 
function.linuxpower.ca

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Linus Torvalds]

On Sat, 9 Nov 2002, Zwane Mwaikambo wrote:
> This is all very confusing, notsc isnn't supposed to work with cpus with 
> TSCs?

No.

You have two different cases:

 - a kernel compiled for TSC-only. This one simply will not _work_ without 
   a TSC, since it is statically compiled for the TSC case. Here, "notsc"
   simply cannot do anything, so it just prints a message saying that it 
   doesn't work.

 - a "generic" kernel, which can do the TSC decision dynamically, will use 
   the TSC flag in the CPU features field to decide whether to use the TSC
   or not. Here, "notsc" will clear the flag unconditionally, so even if 
   your CPU claims to have a TSC, it won't get used.

NOTE! We used to do a lot more statically, and on the whole the hard-coded
CONFIG_X86_TSC usage has pretty much disappeared in modern kernels. It's 
used mainly by the "get_cycles()" macro, which is not all that commonly 
used any more (it used to be used by the scheduler, I think that's gone 
too these days).

		Linus

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Henning P. Schmiedehausen]

Linus Torvalds <torvalds@transmeta.com> writes:


> - a kernel compiled for TSC-only. This one simply will not _work_ without 
>   a TSC, since it is statically compiled for the TSC case. Here, "notsc"
>   simply cannot do anything, so it just prints a message saying that it 
>   doesn't work.

IMHO, if you boot a "TSC-only" kernel on a machine without TSC, the correct
answer should be 

Panic: This kernel is compiled for TSC-only. No TSC found.
Machine halted.

Same goes IMHO for "i686 on lower", "i586 on lower" and so on. 

Everything else leads to strange effects and hard to decipher bug
reports. If in doubt, boot i386 compiled kernel.

	Regards
		Henning



-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Maciej W. Rozycki]

On Sun, 10 Nov 2002, Henning P. Schmiedehausen wrote:

> > - a kernel compiled for TSC-only. This one simply will not _work_ without 
> >   a TSC, since it is statically compiled for the TSC case. Here, "notsc"
> >   simply cannot do anything, so it just prints a message saying that it 
> >   doesn't work.
> 
> IMHO, if you boot a "TSC-only" kernel on a machine without TSC, the correct
> answer should be 
> 
> Panic: This kernel is compiled for TSC-only. No TSC found.
> Machine halted.

 And that happens -- see check_config() in <asm-i386/bugs.h>.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH][2.5] notsc option needs some attention/TLC

[William Lee Irwin III]

On Sat, Nov 09, 2002 at 10:51:27AM -0800, Linus Torvalds wrote:
> No.
> You have two different cases:
>  - a kernel compiled for TSC-only. This one simply will not _work_ without 
>    a TSC, since it is statically compiled for the TSC case. Here, "notsc"
>    simply cannot do anything, so it just prints a message saying that it 
>    doesn't work.
>  - a "generic" kernel, which can do the TSC decision dynamically, will use 
>    the TSC flag in the CPU features field to decide whether to use the TSC
>    or not. Here, "notsc" will clear the flag unconditionally, so even if 
>    your CPU claims to have a TSC, it won't get used.
> NOTE! We used to do a lot more statically, and on the whole the hard-coded
> CONFIG_X86_TSC usage has pretty much disappeared in modern kernels. It's 
> used mainly by the "get_cycles()" macro, which is not all that commonly 
> used any more (it used to be used by the scheduler, I think that's gone 
> too these days).

Then the options have been mangled and it doesn't do this right anymore,
with the net result that there's no way to turn off TSC synch ever. I've
narrowed this down to config options setting CONFIG_X86_TSC for at least for
all cpu revisions > 586 plus unconditional TSC usage given CONFIG_X86_TSC.


Bill

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Linus Torvalds]

On Sun, 10 Nov 2002, William Lee Irwin III wrote:
> 
> Then the options have been mangled and it doesn't do this right anymore,
> with the net result that there's no way to turn off TSC synch ever. I've
> narrowed this down to config options setting CONFIG_X86_TSC for at least for
> all cpu revisions > 586

But that's the point. If you specify that you have a CPU > 586, then you 
specify at compile-time that you have TSC.

If your TSC is broken, then you shouldn't do that. You should compile for 
"generic x86" (386), and then say "notsc".

(Yeah, it should work for i486 too, but in general it's the "generic 386"  
that should work on all machines because it doesn't assume anything about
the capabilities of the machine).

But considering that we don't use the static TSC knowledge very much any
more, you might want to remove CONFIG_X86_TSC altogether, though, and
replace its uses with run-time checks. We've done that with a lot of the
other config stuff earlier (SSE/XMM) because the static compiled options
are just too inconvenient and not worth the maintenance hassles..

		Linus

Re: [PATCH][2.5] notsc option needs some attention/TLC

[William Lee Irwin III]

On Sun, Nov 10, 2002 at 05:51:37PM -0800, Linus Torvalds wrote:
> But that's the point. If you specify that you have a CPU > 586, then you 
> specify at compile-time that you have TSC.
> If your TSC is broken, then you shouldn't do that. You should compile for 
> "generic x86" (386), and then say "notsc".
> (Yeah, it should work for i486 too, but in general it's the "generic 386"  
> that should work on all machines because it doesn't assume anything about
> the capabilities of the machine).
> But considering that we don't use the static TSC knowledge very much any
> more, you might want to remove CONFIG_X86_TSC altogether, though, and
> replace its uses with run-time checks. We've done that with a lot of the
> other config stuff earlier (SSE/XMM) because the static compiled options
> are just too inconvenient and not worth the maintenance hassles..

Performance considerations make compiling for 386 a relatively poor
solution. I'm very much in favor of the runtime checks and will
intensively investigate that method of dealing with the situation, and
with any luck follow up soon with a solution acceptable to both you and
others for this dynamic TSC usage issue.


Thanks,
Bill

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Alan Cox]

On Mon, 2002-11-11 at 01:51, Linus Torvalds wrote:
> But considering that we don't use the static TSC knowledge very much any
> more, you might want to remove CONFIG_X86_TSC altogether, though, and
> replace its uses with run-time checks. We've done that with a lot of the
> other config stuff earlier (SSE/XMM) because the static compiled options
> are just too inconvenient and not worth the maintenance hassles..

Or we use the new config stuff to stick in

Twiddle Advanced Bits Y/N
	Include PPro fence fix
	Include ...
	Include ...
	

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Alan Cox]

On Sat, 2002-11-09 at 18:09, Zwane Mwaikambo wrote:
> > 2.4 was modified to printk a message that TSC was not disabled. This
> > does confuse people
> 
> This is all very confusing, notsc isnn't supposed to work with cpus with 
> TSCs?

User boots TSC only kernel
User gets problem
User reads docs and says "notsc"
User still has problem
User confused.

In the TSC only case printing a message that the TSC disable was not
possible is IMHO good

Re: [PATCH][2.5] notsc option needs some attention/TLC

[J.E.J. Bottomley]

> having this config option ass-backwards is mind-bogglingly confusing,
> and there seems no real reason for it. John had a plan to just put  in
> CONFIG_X86_PIT instead as the inverse of this, and delete
> CONFIG_X86_TSC. He seems to have gone off this idea for some reason I
> can't understand ... I think it solves a lot of these issues ...

Actually, this is partly my fault.  When the subarch code went in, the meaning 
of CONFIG_X86_TSC got altered to mean, 'If not y, don't use tsc at all' (so I 
could disable the TSC entirely for Voyager). Then, when code moved to 
kernel/timers we got some code with the old meaning and some with the new, 
hence the confusion.

The CONFIG_X86_PIT was something I added to try to clarify.  There are three 
cases with this:

PIT y, TSC n: Never use TSC, always use PIT
PIT y, TSC y: Try TSC at first, if it doesn't work, fall back to PIT
PIT n, TSC y: TSC always works, use it without testing.

Obviously PIT n, TSC n is bogus.

There are also two distinct usages of TSC:

1. do_fast_gettimeofday (now in timers) which *requires* the TSCs to be 
synchronised across all CPUs
2. more accurate udelay (which already has the mechanisms in place to cope 
with TSCs running at different rates).

1. is usually the reason why numa like machines want to disable the TSC 
entirely.

Linus isn't very happy with the global TSC disable patch (see 
http://marc.theaimsgroup.com/?t=103652952900006&r=1&w=2).  And wants a better 
solution.  (Then, of course, there are the additional timer options, like the 
cyclone).

James

Re: [PATCH][2.5] notsc option needs some attention/TLC

[Zwane Mwaikambo]

On Sat, 9 Nov 2002, J.E.J. Bottomley wrote:

> The CONFIG_X86_PIT was something I added to try to clarify.  There are three 
> cases with this:
> 
> PIT y, TSC n: Never use TSC, always use PIT
> PIT y, TSC y: Try TSC at first, if it doesn't work, fall back to PIT
> PIT n, TSC y: TSC always works, use it without testing.
> 
> Obviously PIT n, TSC n is bogus.

<n00b> How does one go about building a kernel with PIT y and TSC y ? My 
current kernels obviously are incapable of disabling the TSC </n00b>

	Zwane
-- 
function.linuxpower.ca

Re: [PATCH][2.5] notsc option needs some attention/TLC

[J.E.J. Bottomley]

zwane@holomorphy.com said:
> <n00b> How does one go about building a kernel with PIT y and TSC y ?
> My  current kernels obviously are incapable of disabling the TSC </
> n00b> 

The PIT patches come with the voyager stuff (which isn't integrated yet).  
However, they are broken out at

http://linux-voyager.bkbits.net/timer-2.5

if you have bitkeeper.

On a current kernel, if you build with TSC n, it should have the same effect.

James

[PATCH][2.5] notsc option needs some attention/TLC

[Zwane Mwaikambo]

notsc doesn't work on a box with a TSC, when we need need the option the 
most...

Index: linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c
===================================================================
RCS file: /build/cvsroot/linux-2.5.46/arch/i386/kernel/cpu/common.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 common.c
--- linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c	5 Nov 2002 01:47:31 -0000	1.1.1.1
+++ linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c	9 Nov 2002 03:10:45 -0000
@@ -12,6 +12,11 @@
 
 static int cachesize_override __initdata = -1;
 static int disable_x86_fxsr __initdata = 0;
+#ifdef CONFIG_X86_TSC
+static int tsc_disable __initdata = 0;
+#else
+#define tsc_disable	1
+#endif
 
 struct cpu_dev * cpu_devs[X86_VENDOR_NUM] = {};
 
@@ -42,24 +47,14 @@
 }
 __setup("cachesize=", cachesize_setup);
 
-#ifndef CONFIG_X86_TSC
-static int tsc_disable __initdata = 0;
-
+#ifdef CONFIG_X86_TSC
 static int __init tsc_setup(char *str)
 {
 	tsc_disable = 1;
 	return 1;
 }
-#else
-#define tsc_disable 0
-
-static int __init tsc_setup(char *str)
-{
-	printk("notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.\n");
-	return 1;
-}
-#endif
 __setup("notsc", tsc_setup);
+#endif
 
 int __init get_model_name(struct cpuinfo_x86 *c)
 {

-- 
function.linuxpower.ca