Andrew Morton wrote:
> fyi.. (if replying, please be sure to do it on-list)
>
> Begin forwarded message:
>
> Date: Thu, 17 Aug 2006 13:40:42 +0200
> From: Wolfgang Erig <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Regression with hyper threading scheduling
>
>
> Hello kernel hacker,
>
> I have a regression with Hyper-Threading in my box.
>
> If I try e.g. 'while true; do ((ii+=1)); done' on two xterms
> - with 2.6.8 both CPUs are running (looking at gkrellm or /proc/stat)
> - with 2.6.15/2.6.17 etc. only one CPU is running, sometimes CPU0, sometimes CPU1
>
> Any idea? If you need more info, let me know,
> Wolfgang
>
>
> Kernel 2.6.8.1: Hyper-Threading works:
> ======================================
> uname -a
> Linux oak 2.6.8.1 #1 SMP Wed May 10 13:24:21 CEST 2006 i686 GNU/Linux
>
> cat /proc/stat
> cpu 22709 4502 2543 1008491 2881 92 1475
> cpu0 12800 2428 1426 501276 1859 92 1472
> cpu1 9909 2074 1117 507215 1021 0 2
> intr 5909520 5214423 7297 0 2 2 0 2 1 0 0 0 0 92935 0 7422 13 0 224861 42603 0 0 0 319959 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ctxt 6553093
> btime 1155801409
> processes 2525
> procs_running 3
> procs_blocked 0
>
> Kernel 2.6.17.8 etc.: Hyper-Threading does not work:
> ====================================================
> uname -a
> Linux oak 2.6.17.8 #2 SMP PREEMPT Thu Aug 17 11:40:04 CEST 2006 i686 GNU/Linux
>
> cat /proc/stat
> cpu 5049 0 744 137292 3113 18 3 0
> cpu0 36 0 53 72732 282 18 1 0
> cpu1 5012 0 690 64560 2831 0 2 0
> intr 221093 182798 880 0 3 4 0 3 1 0 0 0 0 28863 0 6718 12 1811 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ctxt 458461
> btime 1155807757
> processes 3203
> procs_running 1
> procs_blocked 0
>
> Some HW-Infos:
> ==============
> lshw
> description: Mini Tower Computer
> product: SCENIC P / SCENICO P
> vendor: FUJITSU SIEMENS
> version: SCEP
> serial: YBEM738326
> width: 32 bits
> capabilities: smbios-2.31 dmi-2.31
> configuration: boot=normal chassis=mini-tower uuid=FA48F283-A977-D811-A847-912FD384AB1D
> *-core
> description: Motherboard
> product: D1561
> vendor: FUJITSU SIEMENS
> physical id: 0
> version: S26361-D1561
> slot: Serial-1
> *-firmware
> description: BIOS
> vendor: FUJITSU SIEMENS // Phoenix Technologies Ltd.
> physical id: 0
> version: 5.00 R2.14.1561.01 (11/25/2004)
> size: 109KB
> capacity: 448KB
> capabilities: pci pnp apm upgrade shadowing escd cdboot bootselect int13floppynec int13floppytoshiba int13floppy360 int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb agp ls120boot zipboot biosbootspecification
> *-cpu
> description: CPU
> product: Intel(R) Pentium(R) 4 CPU 2.60GHz
> vendor: Intel Corp.
> physical id: 4
> bus info: cpu@0
> version: 15.2.9
> slot: CPU
> size: 2600MHz
> capacity: 2600MHz
> width: 32 bits
> clock: 800MHz
> capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
> configuration: id=1
> *-cache:0
> description: L1 cache
> physical id: 5
> slot: L1 Cache
> size: 8KB
> capacity: 32KB
> capabilities: burst synchronous internal write-through data
> *-cache:1
> description: L2 cache
> physical id: 6
> slot: L2 Cache
> size: 512KB
> capacity: 1MB
> capabilities: burst internal write-back unified
> *-cache:2 DISABLED
> description: L3 cache
> physical id: 7
> slot: L3 Cache
> capacity: 16MB
> capabilities: internal write-back unified
> *-logicalcpu:0
> description: Logical CPU
> physical id: 1.1
> width: 32 bits
> capabilities: logical
> *-logicalcpu:1
> description: Logical CPU
> physical id: 1.2
> width: 32 bits
> ...
I'm unable to reproduce this problem with 2.6.18-rc4 on my HT system.
I'm using top with the "last processor" field enabled to observe (rather
than the methods described) and the two bash shells are both getting
100% and are each firmly affixed to different CPUs.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Peter Williams wrote:
> Andrew Morton wrote:
>> fyi.. (if replying, please be sure to do it on-list)
>>
>> Begin forwarded message:
>>
>> Date: Thu, 17 Aug 2006 13:40:42 +0200
>> From: Wolfgang Erig <[email protected]>
>> To: [email protected]
>> Cc: [email protected]
>> Subject: Regression with hyper threading scheduling
>>
>>
>> Hello kernel hacker,
>>
>> I have a regression with Hyper-Threading in my box.
>>
>> If I try e.g. 'while true; do ((ii+=1)); done' on two xterms
>> - with 2.6.8 both CPUs are running (looking at gkrellm or /proc/stat)
>> - with 2.6.15/2.6.17 etc. only one CPU is running, sometimes CPU0,
>> sometimes CPU1
>>
>> Any idea? If you need more info, let me know,
>> Wolfgang
>>
>>
>> Kernel 2.6.8.1: Hyper-Threading works:
>> ======================================
>> uname -a
>> Linux oak 2.6.8.1 #1 SMP Wed May 10 13:24:21 CEST 2006 i686 GNU/Linux
>>
>> cat /proc/stat
>> cpu 22709 4502 2543 1008491 2881 92 1475
>> cpu0 12800 2428 1426 501276 1859 92 1472
>> cpu1 9909 2074 1117 507215 1021 0 2
>> intr 5909520 5214423 7297 0 2 2 0 2 1 0 0 0 0 92935 0 7422 13 0 224861
>> 42603 0 0 0 319959 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> ctxt 6553093
>> btime 1155801409
>> processes 2525
>> procs_running 3
>> procs_blocked 0
>>
>> Kernel 2.6.17.8 etc.: Hyper-Threading does not work:
>> ====================================================
>> uname -a
>> Linux oak 2.6.17.8 #2 SMP PREEMPT Thu Aug 17 11:40:04 CEST 2006 i686
>> GNU/Linux
>>
>> cat /proc/stat
>> cpu 5049 0 744 137292 3113 18 3 0
>> cpu0 36 0 53 72732 282 18 1 0
>> cpu1 5012 0 690 64560 2831 0 2 0
>> intr 221093 182798 880 0 3 4 0 3 1 0 0 0 0 28863 0 6718 12 1811 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> ctxt 458461
>> btime 1155807757
>> processes 3203
>> procs_running 1
>> procs_blocked 0
[bits deleted]
>
> I'm unable to reproduce this problem with 2.6.18-rc4 on my HT system.
> I'm using top with the "last processor" field enabled to observe (rather
> than the methods described) and the two bash shells are both getting
> 100% and are each firmly affixed to different CPUs.
Doing a "cat /proc/stat" also indicates that the problem is not present.
I wonder if the two xterms and/or their shells are have different nice
values (or scheduling policies)?
Also is the presence of PREEMPT in the uname output for the 2.6.17.8
kernel (not present in the 2.6.8.1 kernel's output) significant?
Presuming that this signifies the CONFIG_PREEMPT option is selected it
is worth noting that I do not have this selected in the kernel I tested.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Sun, Aug 20, 2006 at 06:04:00PM +1000, Peter Williams wrote:
> ...
> >lshw
> > description: Mini Tower Computer
> > product: SCENIC P / SCENICO P
> > vendor: FUJITSU SIEMENS
> > version: SCEP
> > serial: YBEM738326
> > width: 32 bits
> > capabilities: smbios-2.31 dmi-2.31
> > configuration: boot=normal chassis=mini-tower
> > uuid=FA48F283-A977-D811-A847-912FD384AB1D
> > *-core
> > description: Motherboard
> > product: D1561
> > vendor: FUJITSU SIEMENS
> > physical id: 0
> > version: S26361-D1561
> > slot: Serial-1
> > *-firmware
> > description: BIOS
> > vendor: FUJITSU SIEMENS // Phoenix Technologies Ltd.
> > physical id: 0
> > version: 5.00 R2.14.1561.01 (11/25/2004)
> > size: 109KB
> > capacity: 448KB
> > capabilities: pci pnp apm upgrade shadowing escd cdboot
> > bootselect int13floppynec int13floppytoshiba int13floppy360
> > int13floppy1200 int13floppy720 int13floppy2880 int5printscreen
> > int9keyboard int14serial int17printer int10video acpi usb agp
> > ls120boot zipboot biosbootspecification
> > *-cpu
> > description: CPU
> > product: Intel(R) Pentium(R) 4 CPU 2.60GHz
> > vendor: Intel Corp.
> > physical id: 4
> > bus info: cpu@0
> > version: 15.2.9
> > slot: CPU
> > size: 2600MHz
> > capacity: 2600MHz
> > width: 32 bits
> > clock: 800MHz
> > capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce
> > cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx
> > fxsr sse sse2 ss ht tm pbe cid
> > configuration: id=1
> ...
>
> I'm unable to reproduce this problem with 2.6.18-rc4 on my HT system.
> I'm using top with the "last processor" field enabled to observe (rather
> than the methods described) and the two bash shells are both getting
> 100% and are each firmly affixed to different CPUs.
We can see the problem only on the hardware above.
Another (newer) system runs perfectly:
lshw
description: Mini Tower Computer
product: SCENIC P / SCENICO P
vendor: FUJITSU SIEMENS
version: SCEP2
serial: YBPB012753
width: 32 bits
capabilities: smbios-2.31 dmi-2.31
configuration: boot=normal chassis=mini-tower
uuid=F5585067-4E15-11D9-897B-0030057E3EC7
*-core
description: Motherboard
product: D1931
vendor: FUJITSU SIEMENS
physical id: 0
version: S26361-D1931
serial: 16105060
slot: Serial-1
*-firmware
description: BIOS
vendor: FUJITSU SIEMENS // Phoenix Technologies Ltd.
physical id: 0
version: 5.00 R1.08.1931 (12/03/2004)
size: 110KB
capacity: 448KB
capabilities: pci pnp apm upgrade shadowing escd cdboot
bootselect int13floppynec int13floppytoshiba int13floppy360
int13floppy1200 int13floppy720 int13floppy2880 int5printscreen
int9keyboard int14serial int17printer int10video acpi usb agp
ls120boot zipboot biosbootspecification
*-cpu
description: CPU
product: Intel(R) Pentium(R) 4 CPU 3.20GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
version: 15.4.1
serial: 0000-0F41-0000-0000-0000-0000
slot: CPU
size: 3200MHz
capacity: 3200MHz
width: 32 bits
clock: 800MHz
capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor ds_cpl cid xtpr
configuration: id=0
...
Wolfgang
On Mon, Aug 21, 2006 at 10:42:06AM +1000, Peter Williams wrote:
> Peter Williams wrote:
> >Andrew Morton wrote:
> ...
> >I'm unable to reproduce this problem with 2.6.18-rc4 on my HT system.
> >I'm using top with the "last processor" field enabled to observe (rather
> >than the methods described) and the two bash shells are both getting
> >100% and are each firmly affixed to different CPUs.
>
> Doing a "cat /proc/stat" also indicates that the problem is not present.
>
> I wonder if the two xterms and/or their shells are have different nice
> values (or scheduling policies)?
No.
> Also is the presence of PREEMPT in the uname output for the 2.6.17.8
> kernel (not present in the 2.6.8.1 kernel's output) significant?
> Presuming that this signifies the CONFIG_PREEMPT option is selected it
> is worth noting that I do not have this selected in the kernel I tested.
We have tried witn and without CONFIG_PREEMPT and saw the same problem.
Wolfgang