mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [patch] [sched] x86 idle thread should clear %fs, %gs
@ 2002-01-27 17:37 Ingo Molnar
  2002-01-29  0:04 ` Pavel Machek
  0 siblings, 1 reply; 3+ messages in thread
From: Ingo Molnar @ 2002-01-27 17:37 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel


the idle thread (on SMP, all idle threads) should clear the %fs and %gs
register, we forgot to clear these registers after the boot process. This
is especially important in kernels with the previous %fs/%gs patch
applied. (The patch below is against 2.5.3-pre3.)

i've checked and it apperas that the 0.01 Linux kernel source code has the
same problem, in boot/head.s the idle task loads the 0x10 selector, and
INIT_TASK's init TSS uses the 0x17 selector for %gs and never clears it.
:-)

while it's not an issue from the correctness point of view in the 0.01
kernel either, the TSS switching microcode probably exeutes slightly
faster if %gs is 0 for both tasks.

so it appears that this lowlevel x86 performance bug(?) is more than 11
years old! :-)

	Ingo

--- linux/arch/i386/kernel/setup.c.orig	Sun Jan 27 15:14:43 2002
+++ linux/arch/i386/kernel/setup.c	Sun Jan 27 16:01:34 2002
@@ -2803,9 +2803,10 @@
 	load_TR(nr);
 	load_LDT(&init_mm);

-	/*
-	 * Clear all 6 debug registers:
-	 */
+	/* Clear %fs and %gs. */
+	asm volatile ("xorl %eax, %eax; movl %eax, %fs; movl %eax, %gs");
+
+	/* Clear all 6 debug registers: */

 #define CD(register) __asm__("movl %0,%%db" #register ::"r"(0) );



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [patch] [sched] x86 idle thread should clear %fs, %gs
  2002-01-27 17:37 [patch] [sched] x86 idle thread should clear %fs, %gs Ingo Molnar
@ 2002-01-29  0:04 ` Pavel Machek
  2002-01-31 11:33   ` Ingo Molnar
  0 siblings, 1 reply; 3+ messages in thread
From: Pavel Machek @ 2002-01-29  0:04 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Linus Torvalds, linux-kernel

Hi!

> so it appears that this lowlevel x86 performance bug(?) is more than 11
> years old! :-)

Probably 386's were not optimized for %fs==%gs==0 case?

BTW does it really make a difference for the CPU?
									Pavel

> @@ -2803,9 +2803,10 @@
>  	load_TR(nr);
>  	load_LDT(&init_mm);
> 
> -	/*
> -	 * Clear all 6 debug registers:
> -	 */
> +	/* Clear %fs and %gs. */
> +	asm volatile ("xorl %eax, %eax; movl %eax, %fs; movl %eax, %gs");
> +
> +	/* Clear all 6 debug registers: */
> 
>  #define CD(register) __asm__("movl %0,%%db" #register ::"r"(0) );

-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [patch] [sched] x86 idle thread should clear %fs, %gs
  2002-01-29  0:04 ` Pavel Machek
@ 2002-01-31 11:33   ` Ingo Molnar
  0 siblings, 0 replies; 3+ messages in thread
From: Ingo Molnar @ 2002-01-31 11:33 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Linus Torvalds, linux-kernel


On Tue, 29 Jan 2002, Pavel Machek wrote:

> > so it appears that this lowlevel x86 performance bug(?) is more than 11
> > years old! :-)
>
> Probably 386's were not optimized for %fs==%gs==0 case?
>
> BTW does it really make a difference for the CPU?

whether %fs/%gs is 0 or not? With the current 2.5.3-pre6 task switching
code there definitely is a performance difference, because we optimize the
'both values are 0' case. With the original TSS-based task switching
microcode i suspect it made a difference as well. (switching between two
different %fs/%gs values should be slower.)

	Ingo


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-01-31  9:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-27 17:37 [patch] [sched] x86 idle thread should clear %fs, %gs Ingo Molnar
2002-01-29  0:04 ` Pavel Machek
2002-01-31 11:33   ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®