Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I did get to test the 3.15 kernel over the weekend. There' definitely some improvement. as hdparm -t now reports 25-30MB/s for my hard drive instead of 6-7MB/s. The stutter in audio playback is less pronounced and almost unnoticeable. At this point the dn2800mt board is largely useable with hyperthreading enabled. I'll delve more deeply into this as time allows. On 5/14/2014 4:05 PM, Henrique de Moraes Holschuh wrote: On Wed, 14 May 2014, Paul Ausbeck wrote: While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? Well, I just did a quick hunting for when support was added... commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 Author: Jan Kiszka Date: Sat Jan 25 22:24:22 2014 +0100 intel_idle: Add CPU model 54 (Atom N2000 series) Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition for the previous ATOM series. Tests on N2800 systems showed that this addition is fine an can reduce power consumption by about 0.25 W (personally confirmed on Intel DN2800MT). Signed-off-by: Jan Kiszka Signed-off-by: Len Brown The bad news is that this commit is present only on kernel 3.15-rc. It should be trivial to backport it to older kernels (it really just adds a single line to the table of supported processors), but I didn't check if the atom code in intel-idle received any fixes lately. It might be worthwhile to test it, or to test the latest development 3.15 kernel (get it directly from Linus' git tree). If you're going to test 3.15, do be aware that there's always increased risk of issues when testing a non-released kernel, so the risks and the procedures I gave you for safe testing of bissected kernels DO apply. BTW, it is actually weird that acpi-idle would malfunction _or_ interact badly with firmware, as it usually the more tested and stable idle driver since it operates more closely to that other OS does than intel-idle :-) Hmm, come to think of it, here's something you can try: http://biosbits.org/ It is an official Intel testsuite for the BIOS/EFI. And I *believe* you can actually get it to boot Debian with replacement firmware it provides (my best guess is that it overrides acpi tables and reprograms the processor and chipset). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538376be.3040...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
Curiouser and curiouser. I have a second dn2800mt machine that my girlfriend uses. I ran some tests while there and I'm more uncertain than ever about what is going on. First, hdparm does not report correctly with hyperthreading enabled just as with the original machine. However, the problem is limited to the winchester drive, 3 - 7 MB/s reported read speed, the USB flash drive reports correctly ~30MB/s read timings. Second, the problem shifts following a suspend/resume cycle. The winchester drive then reports ~150MB/s, but the USB flash drive reports ~20MB/s. Third, the hdparm numbers aren't super accurate (well for USB actually pretty accurate) but they correlate to actual read bandwidth. Immediately following boot, USB 680MB 21.5s, winchester 710MB 11.297s. Following suspend/resume, USB 680MB 26.058s, winchester 710MB 5.206s. Caches purged of course and these numbers are repeatable. Fourth, with hyperthreading disabled, hdparm and actual read speeds are as expected, USB 30+MB/s, winchester 120-150MB/s, always. Fifth, boot time to ethernet up with hyperthreading enabled, ~17s, disabled ~27s. Sixth, a CPU bound threading benchmark, sysbench, shows that hyperthreading is accomplishing something, with performance consistent across suspend/resume cycles. Therefore, I'm sort of leaning against a board specific problem and more toward a design specific problem. Also, this problem is tenuous enough to be present in other Intel products but heretofore unnoticed. All experiments with 3.12 kernel. On 5/14/2014 4:05 PM, Henrique de Moraes Holschuh wrote: On Wed, 14 May 2014, Paul Ausbeck wrote: While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? Well, I just did a quick hunting for when support was added... commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 Author: Jan Kiszka Date: Sat Jan 25 22:24:22 2014 +0100 intel_idle: Add CPU model 54 (Atom N2000 series) Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition for the previous ATOM series. Tests on N2800 systems showed that this addition is fine an can reduce power consumption by about 0.25 W (personally confirmed on Intel DN2800MT). Signed-off-by: Jan Kiszka Signed-off-by: Len Brown The bad news is that this commit is present only on kernel 3.15-rc. It should be trivial to backport it to older kernels (it really just adds a single line to the table of supported processors), but I didn't check if the atom code in intel-idle received any fixes lately. It might be worthwhile to test it, or to test the latest development 3.15 kernel (get it directly from Linus' git tree). If you're going to test 3.15, do be aware that there's always increased risk of issues when testing a non-released kernel, so the risks and the procedures I gave you for safe testing of bissected kernels DO apply. BTW, it is actually weird that acpi-idle would malfunction _or_ interact badly with firmware, as it usually the more tested and stable idle driver since it operates more closely to that other OS does than intel-idle :-) Hmm, come to think of it, here's something you can try: http://biosbits.org/ It is an official Intel testsuite for the BIOS/EFI. And I *believe* you can actually get it to boot Debian with replacement firmware it provides (my best guess is that it overrides acpi tables and reprograms the processor and chipset). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5375527f.8020...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Wed, 14 May 2014, Paul Ausbeck wrote: > While examining the kernel log for another reason, I came across > evidence that acpi_idle, and not intel_idle, is being used on my > dn2800mt system, see below. In fact, it seems that intel_idle cannot > be used. Is there some sort of binary blob involved here? Well, I just did a quick hunting for when support was added... commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 Author: Jan Kiszka Date: Sat Jan 25 22:24:22 2014 +0100 intel_idle: Add CPU model 54 (Atom N2000 series) Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition for the previous ATOM series. Tests on N2800 systems showed that this addition is fine an can reduce power consumption by about 0.25 W (personally confirmed on Intel DN2800MT). Signed-off-by: Jan Kiszka Signed-off-by: Len Brown The bad news is that this commit is present only on kernel 3.15-rc. It should be trivial to backport it to older kernels (it really just adds a single line to the table of supported processors), but I didn't check if the atom code in intel-idle received any fixes lately. It might be worthwhile to test it, or to test the latest development 3.15 kernel (get it directly from Linus' git tree). If you're going to test 3.15, do be aware that there's always increased risk of issues when testing a non-released kernel, so the risks and the procedures I gave you for safe testing of bissected kernels DO apply. BTW, it is actually weird that acpi-idle would malfunction _or_ interact badly with firmware, as it usually the more tested and stable idle driver since it operates more closely to that other OS does than intel-idle :-) Hmm, come to think of it, here's something you can try: http://biosbits.org/ It is an official Intel testsuite for the BIOS/EFI. And I *believe* you can actually get it to boot Debian with replacement firmware it provides (my best guess is that it overrides acpi tables and reprograms the processor and chipset). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140514230506.ga26...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
While examining the kernel log for another reason, I came across evidence that acpi_idle, and not intel_idle, is being used on my dn2800mt system, see below. In fact, it seems that intel_idle cannot be used. Is there some sort of binary blob involved here? ---demsg | grep idle-- [0.00] RCU dyntick-idle grace-period acceleration is enabled. [0.197859] cpuidle: using governor ladder [0.197869] cpuidle: using governor menu [1.707710] intel_idle: does not run on family 6 model 54 [5.118568] ACPI: acpi_idle registered with cpuidle -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5373b5bc.8000...@alumni.cse.ucsc.edu
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Fri, 09 May 2014, Paul Ausbeck wrote: > I've actually done dummy file reads and writes previously. Well > actually just writes. And they go at full speed, no matter what > hparm says. For example, your example, works at full speed: > dd if=/dev/zero of=somefile bs=10M count=100 ; You have to call "sync", otherwise you've measured the time to write to the buffer-cache... That said, try this: strace -o /tmp/strace.txt -ttt -T hdparm -t (rest of hdparm command). And check if the timings of the syscalls traced give you any insight on where things are going wrong. Compare HT enabled with HT disabled. > but I wasn't able to find a way to purge the disk cache before I got > sidetracked. Perhaps you know of a magic incantation for that? Yes. You can drop all caches if you issue, as root: sync ; echo 1 > /proc/sys/vm/drop_caches According to https://www.kernel.org/doc/Documentation/sysctl/vm.txt drop_caches --- Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free. To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free reclaimable slab objects (includes dentries and inodes): echo 2 > /proc/sys/vm/drop_caches To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped. This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system. Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended. You may see informational messages in your kernel log when this file is used: cat (1234): drop_caches: 3 These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 3) into drop_caches. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140510214707.ga21...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I've actually done dummy file reads and writes previously. Well actually just writes. And they go at full speed, no matter what hparm says. For example, your example, works at full speed: dd if=/dev/zero of=somefile bs=10M count=100 ; I've tried the analogous read: dd of=/dev/null if=somefile bs=10M count=100 ; but I wasn't able to find a way to purge the disk cache before I got sidetracked. Perhaps you know of a magic incantation for that? Also, if you look at my data again, you'll see that hdparm -T is not affected by the hyperthreading state, it's only hdparm -t that's affected. On 5/9/2014 2:56 PM, Henrique de Moraes Holschuh wrote: On Fri, 09 May 2014, Paul Ausbeck wrote: Henrique, thanks a lot for the detailed reply. I will look at the stuff that you suggested, if only to learn about what I don't know. FYI, the problem doesn't seem related to temperature to me. I'm not ruling it out, I'm just saying it doesn't have that feel. What I mean is that when you mess with the low-level idle loop driver, it is not impossible to get all cores and hardware threads of the CPU stuck at C0 state (i.e. running 100% of the time). This *shoudln't* happen, but still it is best that you are aware of the possibility that you might end up testing the cpu heatsink/cooler as well... But, the system doesn't appear to be THAT much more unresponsive when hyperthreading is enabled over when disabled. So I'm leaning toward the idea that hdparm's calculation is being spoofed somehow. Hmm, there's a way to test. Time how much wall-clock time it takes to write a large file to disk and sync (flush to disk) the result, preferably in single-user mode: sync; date ; dd if=/dev/zero of=somefile bs=10M count=100 ; sync; date That should do it (the above creates an 1GiB file). It will also test the scheduler, as that /dev/zero read does cause syscalls and switches to kernel context. BTW, the output of "hdparm -T" should not vary an order of magnitude. If it does and there is nothing obnoxious running in the background, you've got closer to the problem. I doubt it is something like this, though: your system would be sluggish as all heck... Lastly, the difference in boot times may not be due to the hyperthreading issue, at least directly. There are quite a few Indeed. However, when looking at the timings in the /var/log/dmesg comparison, remember the comparison is less for the timings, and more for everything else. Note that some reordering across boots, even of the same kernel, is perfectly normal.
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Fri, 09 May 2014, Paul Ausbeck wrote: > Henrique, thanks a lot for the detailed reply. I will look at the > stuff that you suggested, if only to learn about what I don't know. > > FYI, the problem doesn't seem related to temperature to me. I'm not > ruling it out, I'm just saying it doesn't have that feel. What I mean is that when you mess with the low-level idle loop driver, it is not impossible to get all cores and hardware threads of the CPU stuck at C0 state (i.e. running 100% of the time). This *shoudln't* happen, but still it is best that you are aware of the possibility that you might end up testing the cpu heatsink/cooler as well... > But, the system doesn't appear to be THAT much more unresponsive > when hyperthreading is enabled over when disabled. So I'm leaning > toward the idea that hdparm's calculation is being spoofed somehow. Hmm, there's a way to test. Time how much wall-clock time it takes to write a large file to disk and sync (flush to disk) the result, preferably in single-user mode: sync; date ; dd if=/dev/zero of=somefile bs=10M count=100 ; sync; date That should do it (the above creates an 1GiB file). It will also test the scheduler, as that /dev/zero read does cause syscalls and switches to kernel context. BTW, the output of "hdparm -T" should not vary an order of magnitude. If it does and there is nothing obnoxious running in the background, you've got closer to the problem. I doubt it is something like this, though: your system would be sluggish as all heck... > Lastly, the difference in boot times may not be due to the > hyperthreading issue, at least directly. There are quite a few Indeed. However, when looking at the timings in the /var/log/dmesg comparison, remember the comparison is less for the timings, and more for everything else. Note that some reordering across boots, even of the same kernel, is perfectly normal. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509215607.gd24...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
Henrique, thanks a lot for the detailed reply. I will look at the stuff that you suggested, if only to learn about what I don't know. FYI, the problem doesn't seem related to temperature to me. I'm not ruling it out, I'm just saying it doesn't have that feel. I look at it like this. hdparm says that disk bandwidth is much lower than it should be, but only when hyperthreading is enabled. But, the system doesn't appear to be THAT much more unresponsive when hyperthreading is enabled over when disabled. So I'm leaning toward the idea that hdparm's calculation is being spoofed somehow. We have bytes/time so either bytes is smaller, or time is larger than an accurate value. Likely, though, the two variables are somewhat conflated. Let's say that hdparm thinks its transferring bytes for '2' seconds, but in reality the system is blocking somewhere and the full '2' seconds is not actually being used. In order to explain the similar responsiveness in actual use, my first guess would be that whenever, say thread 'hdparm' is blocked, another thread, say 'anythingelse' is run instead. I will put this issue in the queue and will work consistently on it as a background task. Forensically, I think the first thing I'll verify is the Timex time between the visual appearance on the display of the various hdparm strings. It's hard to see how the system could be so fooled that watch time is off, but experience begets comfort. Lastly, the difference in boot times may not be due to the hyperthreading issue, at least directly. There are quite a few differences in the kernel log (errors, warnings) between the various versions. So I'll have to spend some time at some point to pin down what these log messages actually mean. On 5/9/2014 12:30 PM, Henrique de Moraes Holschuh wrote: On Thu, 08 May 2014, Paul Ausbeck wrote: Next, I don't agree that this hyperthreading problem reeks of a firmware issue. What it reeks of is a linux kernel issue. I'm not Well, it reeks of bad interaction of Linux and the firmware, which *usually* is caused by bad firmware when an Intel desktop motherboard is involved, and very often fixed by newer firmware. Next, both recommending a firmware update and asking for /proc/cpuinfo were red herrings reminiscent of a conversation with any modern corporate support department. I will state flatly, that *I* asked for cpuinfo because I wanted to know the as-seen-by-the-kernel processor topology, as it is very important for correct operation of the SMP/SMT-aware process scheduler. I also wanted to know the microcode revison level (available in cpuinfo) because Intel did something funny with microcode updates for your processor in the past and I wanted to know if you had a version earlier than version 0x106. that and starting anew with open source. Please give me at least token respect. It's just plain fact that Windows 7 gives one confidence that hyperthreading is functioning properly and linux doesn't Linux Linux interacts very differently with the ACPI and EFI firmware and the low-level hardware (including the processor itself, the interrupt controllers and the memory controllers, the PCIe bridges, the IOMMU...) when compared to Windows 7. Next, from just this one data point, my experience tells me that linux isn't exactly playing friendly with Intel hyperthreading. Given that Intel is not that interested in hyperthreading any more, A single datapoint is indeed not enough. Hyperthreading on Intel Core related microarchs works very well for most workloads, to the point that even the newest Xeon E3v3, E5v2 and E7v2 families have hyperthread-enabled cores on most of the processors. The same goes for most of the Core i5/i7 desktop parts. Intel seems to be still quite interested in HT. It is entirely possible that hyperthreading on Atom does not work nearly as well as in the Core/Xeon as far as I know -- I don't have direct experience with Atom processors -- but a quick google search tells me people usually find HT on Atom to be a performance advantage, though. Next, I don't get what I'm supposed to bisect. Every kernel I've tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with hyperthreading. So it seems unlikely to me that any kernel would function properly. In order to bisect, the first step is to find a correct kernel. Perhaps someone could recommend one. Well, I misunderstood you. I thought there was at least ONE kernel that worked with HT enabled. Indeed, if there is no kernel that works well with HT on your board, bissection is impossible. Next, it's not the case that I was confused. hdparm is still a reliable canary for hyperthreading problems on the dn2800mt motherboard. See attached data below, kernel 3.2.0-4 only . When I agreed with you that hdparm is a very good way to reproduce the probl
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Thu, 08 May 2014, Paul Ausbeck wrote:
> Next, I don't agree that this hyperthreading problem reeks of a
> firmware issue. What it reeks of is a linux kernel issue. I'm not
Well, it reeks of bad interaction of Linux and the firmware, which *usually*
is caused by bad firmware when an Intel desktop motherboard is involved, and
very often fixed by newer firmware.
> Next, both recommending a firmware update and asking for
> /proc/cpuinfo were red herrings reminiscent of a conversation with
> any modern corporate support department. I will state flatly, that
*I* asked for cpuinfo because I wanted to know the as-seen-by-the-kernel
processor topology, as it is very important for correct operation of the
SMP/SMT-aware process scheduler.
I also wanted to know the microcode revison level (available in cpuinfo)
because Intel did something funny with microcode updates for your processor
in the past and I wanted to know if you had a version earlier than version
0x106.
> that and starting anew with open source. Please give me at least
> token respect. It's just plain fact that Windows 7 gives one
> confidence that hyperthreading is functioning properly and linux
> doesn't
Linux Linux interacts very differently with the ACPI and EFI firmware and
the low-level hardware (including the processor itself, the interrupt
controllers and the memory controllers, the PCIe bridges, the IOMMU...) when
compared to Windows 7.
> Next, from just this one data point, my experience tells me that
> linux isn't exactly playing friendly with Intel hyperthreading.
> Given that Intel is not that interested in hyperthreading any more,
A single datapoint is indeed not enough. Hyperthreading on Intel Core
related microarchs works very well for most workloads, to the point that
even the newest Xeon E3v3, E5v2 and E7v2 families have hyperthread-enabled
cores on most of the processors. The same goes for most of the Core i5/i7
desktop parts. Intel seems to be still quite interested in HT.
It is entirely possible that hyperthreading on Atom does not work nearly as
well as in the Core/Xeon as far as I know -- I don't have direct experience
with Atom processors -- but a quick google search tells me people usually
find HT on Atom to be a performance advantage, though.
> Next, I don't get what I'm supposed to bisect. Every kernel I've
> tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with
> hyperthreading. So it seems unlikely to me that any kernel would
> function properly. In order to bisect, the first step is to find a
> correct kernel. Perhaps someone could recommend one.
Well, I misunderstood you. I thought there was at least ONE kernel that
worked with HT enabled. Indeed, if there is no kernel that works well with
HT on your board, bissection is impossible.
> Next, it's not the case that I was confused. hdparm is still a
> reliable canary for hyperthreading problems on the dn2800mt
> motherboard. See attached data below, kernel 3.2.0-4 only . When
I agreed with you that hdparm is a very good way to reproduce the problem
("canary").
> But since my hyperthreading issue has not been trivially resolved on
> this list, I'm sort of assured that I'm not missing that trivial
> something. If after a few more days I still don't have a trivial
> answer, I will file a kernel bug.
One thing comes to mind. Try switching the low-level kernel idle-loop
driver. There are at least two that should work with your processor:
acpi_idle, and intel_idle. Usually, intel_idle will be prefered. Disable
it (compile a kernel with just ACPI idle, or if it is a module, blacklist
it). The acpi-idle driver does things a lot closer than what windows 7
does. Do keep an eye on processor temperature while doing this test.
Other stuff that might show up clues on what is wrong by direct comparison
between HT-enabled and HT-disabled:
/proc/interrupts (interrupt routing and TLB flush behaviour).
/var/log/dmesg
output of lspci -vvv *as root*.
Compare them in the HT-disabled and HT-enabled states.
If it works on your processor, check whether "powertop" shows something
remarkably different in the processor behaviour re. frequency and idle
states when you run with HT enabled, and HT disabled. Do this with hdparm
running, of course. Alternatively, try it using the "turbostat" utility
you can find in the tools/power/x86/turbostat directory inside the kernel
source tree (use the turbostat from 3.12 or 3.13 regardless of kernel
version).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140509193036.ga24...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I don't favor the interleaved response technique, so even if that technique is favored on this list, I'll just stay with keeping enough context so that previous messages don't need frequent reference. Next, I don't agree that this hyperthreading problem reeks of a firmware issue. What it reeks of is a linux kernel issue. I'm not going to replace firmware just to hope that it will fix any issue, much less one with hyperthreading. I've already returned the motherboard once for the the HDMI port failing to function, and as far as I can tell, the Intel fix was to downgrade the firmware to a version older than I had on the machine. So I'm especially not going to randomly upgrade away that fix, even more especially when such an upgrade is irreversible. Next, both recommending a firmware update and asking for /proc/cpuinfo were red herrings reminiscent of a conversation with any modern corporate support department. I will state flatly, that my goal was and is to improve linux. I've been using Microsoft stuff since MS-DOS in 1982. But now at 55, I'm basically jettisoning all that and starting anew with open source. Please give me at least token respect. It's just plain fact that Windows 7 gives one confidence that hyperthreading is functioning properly and linux doesn't Next, from just this one data point, my experience tells me that linux isn't exactly playing friendly with Intel hyperthreading. Given that Intel is not that interested in hyperthreading any more, that would be maybe expected. Hyperthreading was in retrospect a mistake, just like pentium IV, Itanium, letting AMD do ia64 first, iAPX 432. Intel is a history of mistakes. But make no mistake, it's still a powerful company. I'd love for open source to have that kind of power. I'll work on it. Next, I don't get what I'm supposed to bisect. Every kernel I've tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with hyperthreading. So it seems unlikely to me that any kernel would function properly. In order to bisect, the first step is to find a correct kernel. Perhaps someone could recommend one. Next, I wanted to really verify that the 3.2.0-4 kernel also exhibited the hdparm issue as I actually wasn't 100% certain. The reason that I updated the kernel in the first place from 3.2.0-4 to 3.12-0 was to obtain the native resolution on my 1920x1080 monitor and to allow the machine to successfully S3 suspend and resume. The 3.12 kernel did improve those issues, and the machine will now suspend/resume and it will do 1920x1080 albeit at 16 bits/pixel. But for some reason the card still doesn't steal enough memory, it's getting a paltry 4M, to do the 32 bits per pixel that it's perfectly capable of. That's why I've built my own 3.12.9 kernel, to debug the graphics subsystem issue. With all this stuff flying around, I thought that maybe I was confused and hdparm might actually show the correct disk bandwidth on the 3.2.0-4 kernel. Next, it's not the case that I was confused. hdparm is still a reliable canary for hyperthreading problems on the dn2800mt motherboard. See attached data below, kernel 3.2.0-4 only . When hyperthreading is disabled in the bios, hdparm shows the expected disk bandwidth. With hyperthreading enabled, hdparm reports dramatically less than the expected disk bandwidth. The problem is not as "severe" on 3.2.0-4 as on the 3.12 series, but it's still obviously there. Next as a newbie, I don't want to waste valuable kernel developer time unless I'm kind of sure that I'm not missing something obvious. But since my hyperthreading issue has not been trivially resolved on this list, I'm sort of assured that I'm not missing that trivial something. If after a few more days I still don't have a trivial answer, I will file a kernel bug. Last, I don't want anyone to feel insulted by what I have to say or the way that I say it. I'm just a straight shooter from way back. If I compare linux to MS Windows and it doesn't measure up in some fashion, it just means that it should measure up and I'll work to make that happen. _ Data mentioned above starts here ___ /proc/version: Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 #Hyperthreading enabled sudo hdparm -tT /dev/sda: Timing cached reads: 1744 MB in 2.00 seconds = 871.70 MB/sec Timing buffered disk reads: 120 MB in 3.05 seconds = 39.30 MB/sec /dev/sdb: Timing cached reads: 1648 MB in 2.00 seconds = 823.93 MB/sec Timing buffered disk reads: 264 MB in 3.01 seconds = 87.83 MB/sec /dev/sdc: Timing cached reads: 1682 MB in 2.00 seconds = 840.98 MB/sec Timing buffered disk reads: 92 M
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Mon, 05 May 2014, Paul Ausbeck wrote: > I've attached the contents of /proc/cpuinfo below, two copies, one > with hyperthreading disabled and one enabled. As I told you, the *very first thing* you must do is to make sure you're using the latest firmware for your motherboard (*especially* the BIOS/EFI). If you're not, update it. This bug reeks of a firmware issue. cpuinfo looks normal for both cases, and the microcode is newer than anything Intel ever published to the general public. > I've also investigated things a bit further and now I'm thinking > that the hyperthreading state affects the system as a whole, not > just hdparm. That's expected. > First, I've attached hdparm output from the same machine booting to > Windows 7. The reported disk speed is not affected by the > hyperthreading state. I've also attached boot speed measurements > for the two states. Windows 7 boot time with hyperthreading enabled > is 2/3 that when disabled. This would be expected if hyperthreading > is actually worth anything. > > Second, it turns out that the boot speed of linux is either > unaffected by the state of hyperthreading, 3.2 kernel, or adversely > affected by enabling hyperthreading, 3.12 kernel. I've attached I believe you will need to take this to LKML, unfortunately. One information that will help track down the issue, is to try several kernel versions in order to try to pinpoint better when things went bad. LKML: linux-kernel mailing list. > I'm thinking that the hdparm scenario is a good canary for a more > fundamental problem with hyperthreading, at least on my dn2800mt > machine. Perhaps the backports 3.12 kernel hasn't been fully vetted Yes. It makes it trivial to "reproduce the bug", so it would help tracking the issue down immensely. But you'll still need to do it with help from the LKML people, unless you can handle the git bissecting yourself. About git bissect (guides): https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html You can do this: git bissect start git bissect good git bissect bad repeat git bissect good/bad as required to enter all datapoints you alread have or manually tested. You can move to any kernel version you want with "git reset --hard ", compile, test, and then mark it with "git bissect good" or "git bissect bad". git bissect will offer you a new test point when you do that. Hint: when bissecting, for safety, first you should test and mark as "GOOD" or "BAD" released/stable kernels, i.e. v3.12.8, v3.11.5, etc. See above, use "git reset --hard" to move to different kernel versions, recompile, boot, test, "git bissect good"/"git bissect bad", rinse and repeat. Try to use a binary search pattern, to reduce the number of kernels you will have to test. Only after you got reasonably near the issue using the above, should you let "git bissect" choose the test point, because it will usually land you somewhere deep into the release-candidate kernels (or even worse, inside the merge window), and those can be quite broken. Therefore, also for safety, when testing these kernels boot to single-user mode, run the hdparm test, note down what happened in a paper somewhere, and reboot to a known release/stable kernel. Only do any real work (such as the git bissect stuff, compiling, etc) on a safe, known release/stable kernel. Obviously, test single-user mode in your known release/stable kernel first, just to make sure the bug doesn't disappear (or always appear) in single-user mode :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140508134406.ga32...@khazad-dum.debian.net
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
I've attached the contents of /proc/cpuinfo below, two copies, one with hyperthreading disabled and one enabled. I've also investigated things a bit further and now I'm thinking that the hyperthreading state affects the system as a whole, not just hdparm. First, I've attached hdparm output from the same machine booting to Windows 7. The reported disk speed is not affected by the hyperthreading state. I've also attached boot speed measurements for the two states. Windows 7 boot time with hyperthreading enabled is 2/3 that when disabled. This would be expected if hyperthreading is actually worth anything. Second, it turns out that the boot speed of linux is either unaffected by the state of hyperthreading, 3.2 kernel, or adversely affected by enabling hyperthreading, 3.12 kernel. I've attached lines from dmesg below showing the times at which the eth0 link becomes ready under various scenarios. Boot times with hyperthreading enabled also seem more variable. I've seen even longer reported boot times on the 3.12 kernel and with a 3.12.9 kernel I've built myself; in the 20 - 30 second range. I'm thinking that the hdparm scenario is a good canary for a more fundamental problem with hyperthreading, at least on my dn2800mt machine. Perhaps the backports 3.12 kernel hasn't been fully vetted yet, but the stable 3.2 kernel should be showing some improvement in boot speeds with hyperthreading enabled over that with hyperthreading disabled, but isn't. Lastly, hdparm is adversely affected by hyperthreading no matter what kernel version is loaded. C:\>hdparm -t /dev/hda # Windows 7 /dev/hda: # Hyperthreading disabled Timing buffered disk reads: 446 MB in 3.01 seconds = 148.13 MB/sec Boot Duration:31248ms /dev/hda: # Hyperthreading enabled Timing buffered disk reads: 448 MB in 3.01 seconds = 148.80 MB/sec Boot Duration:21692ms # Boot times, hyperthreading enabled Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 [ 14.240113] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Linux version 3.12-0.bpo.1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.12.9-1~bpo70+1 (2014-02-07) [ 15.825840] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready # Boot times, hyperthreading disabled Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 [ 14.049342] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Linux version 3.12-0.bpo.1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.12.9-1~bpo70+1 (2014-02-07) [ 12.556885] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready cat /proc/cpuinfo # hyperthreading disabled processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 54 model name: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz stepping: 1 microcode: 0x10d cpu MHz: 798.000 cache size: 512 KB physical id: 0 siblings: 2 core id: 0 cpu cores: 2 apicid: 0 initial apicid: 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu 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 lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dtherm bogomips: 3733.46 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 54 model name: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz stepping: 1 microcode: 0x10d cpu MHz: 798.000 cache size: 512 KB physical id: 0 siblings: 2 core id: 1 cpu cores: 2 apicid: 2 initial apicid: 2 fdiv_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu 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 lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dtherm bogomips: 3733.46 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: cat /proc/cpuinfo # hyperthreading enabled processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 54 model name: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz stepping: 1 microcode: 0x10d cpu MHz: 798.000 cache size: 512 KB physical id: 0 siblings: 4 cor
Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
On Sun, 04 May 2014, Paul Ausbeck wrote: > when I build a new system. Recently I built a system based upon the > Intel Atom dn2800mt motherboard. When I went to vet disk bandwidth, Please, can you give us the output of "cat /proc/cpuinfo" ? > I obtained unexpectedly slow readings from hdparm. I found that if I > disable hyperthreading in the bios, bandwidth readings are as > expected. I believe the numbers reported by hdparm are incorrect Did you update to the latest available BIOS for your motherboard ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140505001209.ga29...@khazad-dum.debian.net
hdparm -t yields incorrect timings when Intel hyperthreading is enabled
Running Wheezy 7.4, kernel 3.2.0-4-686-pae, also on Debian backports kernel 3.12-0.bpo.1-686-pae sudo hdparm -t /dev/sda /dev/sda: # Hyperthreading enabled in bios Timing buffered disk reads: 36 MB in 3.06 seconds = 11.77 MB/sec # Apparently not correct /dev/sda: # Hyperthreading disabled in bios Timing buffered disk reads: 444 MB in 3.01 seconds = 147.38 MB/sec # Expected for WD10EZRX I've formed the habit of using hdparm to vet basic disk operation when I build a new system. Recently I built a system based upon the Intel Atom dn2800mt motherboard. When I went to vet disk bandwidth, I obtained unexpectedly slow readings from hdparm. I found that if I disable hyperthreading in the bios, bandwidth readings are as expected. I believe the numbers reported by hdparm are incorrect when hyperthreading is enabled. There is no other evidence of disk bandwidth problems, and with hyperthreading enabled the system boots slightly faster to ethernet up, 11.92s, vs 12.45s: [ 12.454118] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx # hyperthreading disabled in bios Has anyone else experienced this problem? I'm wondering if it is general to hyperthreading or specific to my particular atom based machine. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53668679.4080...@alumni.cse.ucsc.edu
Re: Hyperthreading problem with IRQ handling and scheduling
Sven Groot put forth on 3/4/2011 12:42 AM: > My question then is twofold. Firstly, why are all interrupts being handled > by the first CPU? You should read this: http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf > I checked the various /proc/irq/#/smp_affinity entries and > they are all so that's not the issue. By changing the value in > those files to a specific CPU I can get the interrupts to be handled by a > different CPU, but that just moves the problem. No matter what I do, I can't > get them to be handled by more than one CPU. I've tried running irqbalance > but that also didn't help. Is there a way to prevent this interrupt CPU > affinity, and if so would it fix my problem? You can only divide interrupt processing by assigning IRQs to specific CPUs. You can't divide up the stream of interrupts in a round robin fashion. So if you have one device IRQ# that's generating all the interrupts, there's not much you can do to fix this situation. What device is generating these massive interrupts? Network card or disk controller? Note that PCIe NICs often have two interrupts, one for transmit and one for receive. I'm not sure about disk/RAID controllers. It would likely depend on the model. In the NIC case you can stick each IRQ# on a difference CPU. Some motherboards route IRQ signals from given sets of slots to a given CPU socket. Read the documentation for your system board and find out which slot IRQs are routed to which CPU sockets. Simply moving a card to another slot may help significantly if your high IRQ load is due to multiple cards and not just one. > Secondly, why does the scheduler not realize that satisfying natural > affinity is not a good idea if the CPUs involved are logical siblings of > each other on the same physical CPU? I thought that the Linux kernel was > hyperthreading-aware and would take these kinds of things into > consideration. Is this a true shortcoming of the scheduler, or is my system > misconfigured somehow? See my previous reply. And do post about this on lkml. You'll get more thorough answers there. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d70a1ca.1080...@hardwarefreak.com
RE: Hyperthreading problem with IRQ handling and scheduling
Hi Stan, Thanks for your reply. I will bring this to the attention of the system administrator (I have root access but I don't think they'll appreciate me installing a new kernel on my own). I've just discovered that a similar issue can also occur with pure compute tasks (no I/O at all). If I run 8 of those in parallel, some of them will run on logical CPUs of the same physical CPU, and those are slower than the ones that get a physical CPU to themselves. Since there are enough physical CPUs available, I don't believe the scheduler should do this. Hopefully upgrading the kernel will resolve this as well. Thanks, Sven -Original Message- From: Stan Hoeppner [mailto:s...@hardwarefreak.com] Sent: vrijdag 4 maart 2011 16:10 To: debian-user@lists.debian.org Subject: Re: Hyperthreading problem with IRQ handling and scheduling Sven Groot put forth on 3/3/2011 11:28 PM: Hello Sven, > I am using a cluster of machines running Debian 5.0.4, kernel > 2.6.26-2-amd64. These machines have dual Intel Xeon E5530 2.4GHz CPUs, > which are quad-core CPUs with hyperthreading. So that means each > machine has 8 physical CPUs and a total of 16 logical CPUs. > I have run into an apparent issue with the kernel scheduler. Under the > circumstances described below, the scheduler will run two tasks on two > logical CPUs of the same physical CPU, even if all the remaining > physical CPUs are idle. This obviously causes a large slowdown for these tasks. Two things. First, you're running Debian kernel 2.6.26 which, IIRC, doesn't have all the scheduler patches required for both mutli-core and HT support, or simply doesn't have them all enabled, which is the cause of your problem. The following must all be set. You need a new kernel. CONFIG_SCHED_SMT CONFIG_SCHED_MC 1. Install the latest Debian prepackaged lenny-backport kernel on each cluster node: linux-image-2.6.32-bpo.5-amd64_2.6.32-30~bpo50+1_i386.deb http://backports.debian.org/Instructions/ If the nodes don't have direct internet access, preventing installation via apt-get or aptitude, then download the .deb package, copy it to each machine via scp/ftp/nfs/etc, and install it via dpkg: dpkg -i /full/path/to/linux-image-2.6.32-bpo.5-amd64_2.6.32-30~bpo50+1_i386.deb I've never installed a backport package directly via dpkg. You may need an additional switch or two. Others here can answer this. 2. Download the 2.6.37.2 vanilla source from: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.2.tar.bz2 Follow the build instructions here: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html to create a kernel image with the options and modules you need, and none you don't, and to create a kernel deb package. Copy the .deb to each cluster node and perform: dpkg -i /full/path/to/linux-image-2.6.37.2-custom.1.0_amd64.deb Second, you may want to ask about this on lkml as well, as far more expertise in this area of the kernel resides there. Installing a new kernel will solve the bulk of your problem. To fine tune the performance per core/thread afterward you'll need assistance from kernel devs on lkml. Hope this points you in the right direction. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d709039.80...@hardwarefreak.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/001201cbda3c$99e92f00$cdbb8d00$@gmail.com
Re: Hyperthreading problem with IRQ handling and scheduling
Sven Groot put forth on 3/3/2011 11:28 PM: Hello Sven, > I am using a cluster of machines running Debian 5.0.4, kernel > 2.6.26-2-amd64. These machines have dual Intel Xeon E5530 2.4GHz CPUs, which > are quad-core CPUs with hyperthreading. So that means each machine has 8 > physical CPUs and a total of 16 logical CPUs. > I have run into an apparent issue with the kernel scheduler. Under the > circumstances described below, the scheduler will run two tasks on two > logical CPUs of the same physical CPU, even if all the remaining physical > CPUs are idle. This obviously causes a large slowdown for these tasks. Two things. First, you're running Debian kernel 2.6.26 which, IIRC, doesn't have all the scheduler patches required for both mutli-core and HT support, or simply doesn't have them all enabled, which is the cause of your problem. The following must all be set. You need a new kernel. CONFIG_SCHED_SMT CONFIG_SCHED_MC 1. Install the latest Debian prepackaged lenny-backport kernel on each cluster node: linux-image-2.6.32-bpo.5-amd64_2.6.32-30~bpo50+1_i386.deb http://backports.debian.org/Instructions/ If the nodes don't have direct internet access, preventing installation via apt-get or aptitude, then download the .deb package, copy it to each machine via scp/ftp/nfs/etc, and install it via dpkg: dpkg -i /full/path/to/linux-image-2.6.32-bpo.5-amd64_2.6.32-30~bpo50+1_i386.deb I've never installed a backport package directly via dpkg. You may need an additional switch or two. Others here can answer this. 2. Download the 2.6.37.2 vanilla source from: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.2.tar.bz2 Follow the build instructions here: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html to create a kernel image with the options and modules you need, and none you don't, and to create a kernel deb package. Copy the .deb to each cluster node and perform: dpkg -i /full/path/to/linux-image-2.6.37.2-custom.1.0_amd64.deb Second, you may want to ask about this on lkml as well, as far more expertise in this area of the kernel resides there. Installing a new kernel will solve the bulk of your problem. To fine tune the performance per core/thread afterward you'll need assistance from kernel devs on lkml. Hope this points you in the right direction. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d709039.80...@hardwarefreak.com
Hyperthreading problem with IRQ handling and scheduling
Hello all, I am using a cluster of machines running Debian 5.0.4, kernel 2.6.26-2-amd64. These machines have dual Intel Xeon E5530 2.4GHz CPUs, which are quad-core CPUs with hyperthreading. So that means each machine has 8 physical CPUs and a total of 16 logical CPUs. I have run into an apparent issue with the kernel scheduler. Under the circumstances described below, the scheduler will run two tasks on two logical CPUs of the same physical CPU, even if all the remaining physical CPUs are idle. This obviously causes a large slowdown for these tasks. What I'm doing is this. I have a simple process that reads a file from disk and performs some computation. The process is largely CPU bound, so if execution of one such task takes N seconds, I would expect execution of two parallel tasks to also take N seconds in the absence of other tasks on the system. However, if these two tasks are the only thing running in the system, the scheduler will consistently assign one task to CPU 0 and the other to CPU 8. Since these are logical CPUs on the same physical CPU, the actual run time of the two parallel task is closer to 1.8N, much slower than what is possible. The problem seems to arise from I/O interrupt handling. If I look at /proc/interrupts, it seems that all interrupts are handled by the first physical CPU. These are then apparently processed by one of this CPUs logical CPUs (which corresponds to CPU 0 and 8). Once the tasks have run on these CPUs, natural affinity ensures that the kernel scheduler will keep them there. This leads to the interesting observation that if I create two tasks that do no I/O (for example because all their I/O requests could be satisfied by the cache) it is scheduled on two random CPUs and runs fast, but if there is even a single I/O operation causing an interrupt anywhere in the process, from that point on the tasks stay on CPU 0 and 8, even if they do no further I/O, and will be much slower. It seems to me that the proper behavior for the kernel scheduler should be to give a higher penalty to running a task on a logical CPU whose logical sibling is also being used while other physical CPUs are available than it does to moving a thread to a different CPU, but it appears that isn't the case. I can work around this issue by setting CPU affinity for the tasks to CPUs 0-7, effectively disabling hyperthreading. However, this is not an ideal solution. My question then is twofold. Firstly, why are all interrupts being handled by the first CPU? I checked the various /proc/irq/#/smp_affinity entries and they are all so that's not the issue. By changing the value in those files to a specific CPU I can get the interrupts to be handled by a different CPU, but that just moves the problem. No matter what I do, I can't get them to be handled by more than one CPU. I've tried running irqbalance but that also didn't help. Is there a way to prevent this interrupt CPU affinity, and if so would it fix my problem? Secondly, why does the scheduler not realize that satisfying natural affinity is not a good idea if the CPUs involved are logical siblings of each other on the same physical CPU? I thought that the Linux kernel was hyperthreading-aware and would take these kinds of things into consideration. Is this a true shortcoming of the scheduler, or is my system misconfigured somehow? I hope you will be able to help. Thanks, Sven
Hyperthreading problem with IRQ handling and scheduling
Hello all, I am using a cluster of machines running Debian 5.0.4, kernel 2.6.26-2-amd64. These machines have dual Intel Xeon E5530 2.4GHz CPUs, which are quad-core CPUs with hyperthreading. So that means each machine has 8 physical CPUs and a total of 16 logical CPUs. I have run into an apparent issue with the kernel scheduler. Under the circumstances described below, the scheduler will run two tasks on two logical CPUs of the same physical CPU, even if all the remaining physical CPUs are idle. This obviously causes a large slowdown for these tasks. What I'm doing is this. I have a simple process that reads a file from disk and performs some computation. The process is largely CPU bound, so if execution of one such task takes N seconds, I would expect execution of two parallel tasks to also take N seconds in the absence of other tasks on the system. However, if these two tasks are the only thing running in the system, the scheduler will consistently assign one task to CPU 0 and the other to CPU 8. Since these are logical CPUs on the same physical CPU, the actual run time of the two parallel task is closer to 1.8N, much slower than what is possible. The problem seems to arise from I/O interrupt handling. If I look at /proc/interrupts, it seems that all interrupts are handled by the first physical CPU. These are then apparently processed by one of this CPUs logical CPUs (which corresponds to CPU 0 and 8). Once the tasks have run on these CPUs, natural affinity ensures that the kernel scheduler will keep them there. This leads to the interesting observation that if I create two tasks that do no I/O (for example because all their I/O requests could be satisfied by the cache) it is scheduled on two random CPUs and runs fast, but if there is even a single I/O operation causing an interrupt anywhere in the process, from that point on the tasks stay on CPU 0 and 8, even if they do no further I/O, and will be much slower. It seems to me that the proper behavior for the kernel scheduler should be to give a higher penalty to running a task on a logical CPU whose logical sibling is also being used while other physical CPUs are available than it does to moving a thread to a different CPU, but it appears that isn't the case. I can work around this issue by setting CPU affinity for the tasks to CPUs 0-7, effectively disabling hyperthreading. However, this is not an ideal solution. My question then is twofold. Firstly, why are all interrupts being handled by the first CPU? I checked the various /proc/irq/#/smp_affinity entries and they are all so that's not the issue. By changing the value in those files to a specific CPU I can get the interrupts to be handled by a different CPU, but that just moves the problem. No matter what I do, I can't get them to be handled by more than one CPU. I've tried running irqbalance but that also didn't help. Is there a way to prevent this interrupt CPU affinity, and if so would it fix my problem? Secondly, why does the scheduler not realize that satisfying natural affinity is not a good idea if the CPUs involved are logical siblings of each other on the same physical CPU? I thought that the Linux kernel was hyperthreading-aware and would take these kinds of things into consideration. Is this a true shortcoming of the scheduler, or is my system misconfigured somehow? I hope you will be able to help. Thanks, Sven
Re: Debian hyperthreading support
On Sat, 02 Oct 2010 20:42:01 -0500, Mark wrote in message <4ca7df69.7040...@allums.com>: > On 10/2/2010 6:08 PM, Nathen wrote: > > Pretty simple question really, does Debian i.e. the current Linux > > Kernel handle hyperthreading well? I have a server running on an > > Intel Atom D510, should I have HT enabled or disabled to get the > > best performance? > > Thanks. :) > > > > > > > Recently (kernel 2.6.31 or so) there has been a separate kernel > configuration option to optimize for SMT (Intel's word for it is > "hyperthreading"). Separate from SMP (multiple processor). Under > SMT, a single core running two threads looks like two cores to most > of the kernel itself and to user programs. This has been true for a > long time. Only now, there is more support and optimization for it. > If your kernel has it enabled, some workloads won't see any > difference, but some will benefit a lot. I think it is enabled by > default in the most recent stock kernels (please correct me if I'm > wrong.) > > Note, you may need to enable hyperthreading in your BIOS, as well. > > I would enable it for Core i7 and Atom. P4-era machines could > sometimes have software compatibility issues with it enabled, ..details, please, I'm trying to figure out what I did wrong in my X|dri|etc setup on my FlightGear P4. > but I think Debian and Atoms are good. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101024210729.5a6f6...@a45.fmb.no
Re: Debian hyperthreading support
On Sun, 03 Oct 2010 01:21:33 +0100, Nathen wrote: > Thanks for replying. The system is running mainly a file server so it's > not very CPU-intensive, I wanted to be sure I wasn't wasting performance > by having it enabled, for example. Thanks I don't think you are going to get any penalty in performance by using a kernel with HT enabled (in fact, that could have happened for some P4 featuring the "replay system" but I fairly doubt it is still live in Atom based CPUs) :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.10.03.12.13...@gmail.com
Re: Debian hyperthreading support
On 10/2/2010 6:08 PM, Nathen wrote: Pretty simple question really, does Debian i.e. the current Linux Kernel handle hyperthreading well? I have a server running on an Intel Atom D510, should I have HT enabled or disabled to get the best performance? Thanks. :) Recently (kernel 2.6.31 or so) there has been a separate kernel configuration option to optimize for SMT (Intel's word for it is "hyperthreading"). Separate from SMP (multiple processor). Under SMT, a single core running two threads looks like two cores to most of the kernel itself and to user programs. This has been true for a long time. Only now, there is more support and optimization for it. If your kernel has it enabled, some workloads won't see any difference, but some will benefit a lot. I think it is enabled by default in the most recent stock kernels (please correct me if I'm wrong.) Note, you may need to enable hyperthreading in your BIOS, as well. I would enable it for Core i7 and Atom. P4-era machines could sometimes have software compatibility issues with it enabled, but I think Debian and Atoms are good. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca7df69.7040...@allums.com
Re: Debian hyperthreading support
Thanks for replying. The system is running mainly a file server so it's not very CPU-intensive, I wanted to be sure I wasn't wasting performance by having it enabled, for example. Thanks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikpvrspjaocbmh_xuhowe9imgx9gkszqaeba...@mail.gmail.com
Re: Debian hyperthreading support
On Sun, 3 Oct 2010 00:08:30 +0100 Nathen wrote: > Pretty simple question really, does Debian i.e. the current Linux > Kernel handle hyperthreading well? I have a server running on an Intel > Atom D510, should I have HT enabled or disabled to get the best > performance? > Thanks. :) > > Sorry, the link was bad (for p4 hyperthreading) its late, my bad. Reading more, it seems that with the atom, hyperthreading really helps with parallel tasks, so I would leave it on. I cant find any benchmarks of it on vs it off, and I dont have a spare HDD to boot the atom330 I have to do some of my own. -- Regards, Angus Hedger Debian GNU/Linux User PGP Public Key 0xEE6A4B97 signature.asc Description: PGP signature
Re: Debian hyperthreading support
On Sun, 3 Oct 2010 00:08:30 +0100 Nathen wrote: > Pretty simple question really, does Debian i.e. the current Linux > Kernel handle hyperthreading well? I have a server running on an Intel > Atom D510, should I have HT enabled or disabled to get the best > performance? > Thanks. :) > > Linux has handled hyperthreading since 2.4.x. As for performance, see here [1] in general it doesn’t hurt performance, but doesn’t help much either. [1] http://java-monitor.com/forum/showthread.php?t=552 -- Regards, Angus Hedger Debian GNU/Linux User PGP Public Key 0xEE6A4B97 signature.asc Description: PGP signature
Debian hyperthreading support
Pretty simple question really, does Debian i.e. the current Linux Kernel handle hyperthreading well? I have a server running on an Intel Atom D510, should I have HT enabled or disabled to get the best performance? Thanks. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikct81umaw_uoldhnl3_csp+mahuobzr=_p8...@mail.gmail.com
Re: How to enable/use Hyperthreading?
On Fri, 10 Nov 2006, Colin wrote: I don't think Pentium D processors are suppose to have two cores. Some of them have hyperthreading which can make then behave like they have two cores. The Pentium D (dual) has two physical cores smudged together on one die, for a total of two cores. The Pentium D Extreme(955,965,etc) has two physical cores that each have a hyperthreaded side as well, making for 4 "cores".. and for the thousand US dollars it costs, it'd better have all 4. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to enable/use Hyperthreading?
Rogério Brito wrote: > I bought recently a new computer with a Pentium D processor (which is > supposed to have two cores, if I understand it) and one of the first > things that I did with it was to enable SMP. > I don't think Pentium D processors are suppose to have two cores. Some of them have hyperthreading which can make then behave like they have two cores. > Seeing in /proc/cpuinfo that the CPU supports Hyperthreading (the ht > flag is in the supported CPU features of this computer), Just because the ht flag is there doesn't mean that supports hyperthreading (strange but true). > I compiled a > brand new kernel (2.6.19-rc4 at the time) and answered Yes to the option > of using Symmetrict Multithreading (aka Hyperthreading in Intel-speak). > > I posted things that I thought were relevant at > http://www.ime.usp.br/~rbrito/pentium-d/ and it shows two processors, > but I don't actually know if they are two "real" processors (cores) or > two "virtual" processors (1 processor with hyperthreading). Again, I think you have one core which looks like two processors. > Also, the dmesg put there doesn't mention that the system has > hyperthreading enabled after I booted it with the acpi=ht kernel > option. If you run "top" and see some process names with "/0" or "/1" at the end, then you are running an "smp" kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to enable/use Hyperthreading?
Hi there, People. I have a question and haven't been able to get an answer for a week already. I bought recently a new computer with a Pentium D processor (which is supposed to have two cores, if I understand it) and one of the first things that I did with it was to enable SMP. Seeing in /proc/cpuinfo that the CPU supports Hyperthreading (the ht flag is in the supported CPU features of this computer), I compiled a brand new kernel (2.6.19-rc4 at the time) and answered Yes to the option of using Symmetrict Multithreading (aka Hyperthreading in Intel-speak). I posted things that I thought were relevant at http://www.ime.usp.br/~rbrito/pentium-d/ and it shows two processors, but I don't actually know if they are two "real" processors (cores) or two "virtual" processors (1 processor with hyperthreading). Also, the dmesg put there doesn't mention that the system has hyperthreading enabled after I booted it with the acpi=ht kernel option. I would love to know if anybody could help me with this. Thanks in advance for any help, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hyperthreading not working (?)... /proc/cpuinfo shows 2 cpus
HT enables the CPU to behave like two processors, that's what Intel wanted to do. No two rela seperated cores but the can be loaded differently. Regards, Michael Przysucha (NDS, Germany) 07.01.2006 07:43:50, Brandon Simmons <[EMAIL PROTECTED]> wrote: >HI >I have just spent hours trying to figure this out, through google >but no luck. I have a single pentium 4 w/ hyperthreading and am >running kernel 2.6.13. I built my own kernel and enabled HT and >the system seems to recognize two processors. > >Here is /proc/cpuinfo: > >/--\ >processor : 0 >vendor_id : GenuineIntel >cpu family : 15 >model : 2 >model name : Intel(R) Pentium(R) 4 CPU 3.00GHz >stepping : 9 >cpu MHz: 3000.571 >cache size : 512 KB >physical id: 0 >siblings : 2 >core id: 0 >cpu cores : 1 >fdiv_bug : no >hlt_bug: no >f00f_bug : no >coma_bug : no >fpu: yes >fpu_exception : yes >cpuid level: 2 >wp : yes >flags : fpu 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 xtpr >bogomips : 6008.35 > >processor : 1 >vendor_id : GenuineIntel >cpu family : 15 >model : 2 >model name : Intel(R) Pentium(R) 4 CPU 3.00GHz >stepping : 9 >cpu MHz: 3000.571 >cache size : 512 KB >physical id: 0 >siblings : 2 >core id: 0 >cpu cores : 1 >fdiv_bug : no >hlt_bug: no >f00f_bug : no >coma_bug : no >fpu: yes >fpu_exception : yes >cpuid level: 2 >wp : yes >flags : fpu 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 xtpr >bogomips : 6000.59 >\/ > >But I can't find any sign that HT is working properly. Here is my >/proc/interrupts file showing only one processor doing anything: > >/\ > CPU0 CPU1 > 0: 830982 0IO-APIC-edge timer > 1: 29760IO-APIC-edge i8042 > 2: 0 0 XT-PIC cascade > 12: 2119 0IO-APIC-edge i8042 > 14: 10163 0IO-APIC-edge ide0 > 15: 29646 0IO-APIC-edge ide1 > 16: 236276 0 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb4 > 17: 0 0 IO-APIC-level Intel ICH5, Intel ICH5 Modem > 18: 0 0 IO-APIC-level uhci_hcd:usb3 > 19: 0 0 IO-APIC-level uhci_hcd:usb2 > 21: 3 0 IO-APIC-level ohci1394 > 22: 70223 0 IO-APIC-level eth0 > 23: 2 0 IO-APIC-level ehci_hcd:usb5 >NMI: 0 0 >LOC: 830932 830931 >ERR: 0 >MIS: 0 >\---/ > >I believe I have all the necessary kernel options enabled >but I may be doing something wrong. I saw some posts >about including 'acpismp=force' to the boot parameters >but I think these were for old 2.4 kernels. > >Thanks for your help, >Brandon > > === Michael Przysucha (Webmaster, Mailmaster) === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hyperthreading not working (?)... /proc/cpuinfo shows 2 cpus
HT enables the CPU to behave like two processors, that's what Intel wanted to do. No two rela seperated cores but the can be loaded differently. Regards, Michael Przysucha (NDS, Germany) 07.01.2006 07:43:50, Brandon Simmons <[EMAIL PROTECTED]> wrote: >HI >I have just spent hours trying to figure this out, through google >but no luck. I have a single pentium 4 w/ hyperthreading and am >running kernel 2.6.13. I built my own kernel and enabled HT and >the system seems to recognize two processors. > >Here is /proc/cpuinfo: > >/--\ >processor : 0 >vendor_id : GenuineIntel >cpu family : 15 >model : 2 >model name : Intel(R) Pentium(R) 4 CPU 3.00GHz >stepping : 9 >cpu MHz: 3000.571 >cache size : 512 KB >physical id: 0 >siblings : 2 >core id: 0 >cpu cores : 1 >fdiv_bug : no >hlt_bug: no >f00f_bug : no >coma_bug : no >fpu: yes >fpu_exception : yes >cpuid level: 2 >wp : yes >flags : fpu 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 xtpr >bogomips : 6008.35 > >processor : 1 >vendor_id : GenuineIntel >cpu family : 15 >model : 2 >model name : Intel(R) Pentium(R) 4 CPU 3.00GHz >stepping : 9 >cpu MHz: 3000.571 >cache size : 512 KB >physical id: 0 >siblings : 2 >core id: 0 >cpu cores : 1 >fdiv_bug : no >hlt_bug: no >f00f_bug : no >coma_bug : no >fpu: yes >fpu_exception : yes >cpuid level: 2 >wp : yes >flags : fpu 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 xtpr >bogomips : 6000.59 >\/ > >But I can't find any sign that HT is working properly. Here is my >/proc/interrupts file showing only one processor doing anything: > >/\ > CPU0 CPU1 > 0: 830982 0IO-APIC-edge timer > 1: 29760IO-APIC-edge i8042 > 2: 0 0 XT-PIC cascade > 12: 2119 0IO-APIC-edge i8042 > 14: 10163 0IO-APIC-edge ide0 > 15: 29646 0IO-APIC-edge ide1 > 16: 236276 0 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb4 > 17: 0 0 IO-APIC-level Intel ICH5, Intel ICH5 Modem > 18: 0 0 IO-APIC-level uhci_hcd:usb3 > 19: 0 0 IO-APIC-level uhci_hcd:usb2 > 21: 3 0 IO-APIC-level ohci1394 > 22: 70223 0 IO-APIC-level eth0 > 23: 2 0 IO-APIC-level ehci_hcd:usb5 >NMI: 0 0 >LOC: 830932 830931 >ERR: 0 >MIS: 0 >\---/ > >I believe I have all the necessary kernel options enabled >but I may be doing something wrong. I saw some posts >about including 'acpismp=force' to the boot parameters >but I think these were for old 2.4 kernels. > >Thanks for your help, >Brandon > > === Michael Przysucha (Webmaster, Mailmaster) === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hyperthreading not working (?)... /proc/cpuinfo shows 2 cpus
What is meant by not working? /proc/cpuinfo shows two processors: cpu 0 and cpu 1. -ishwar On Sat, 7 Jan 2006, Brandon Simmons wrote: > running kernel 2.6.13. I built my own kernel and enabled HT and > the system seems to recognize two processors. > > Here is /proc/cpuinfo: > > /--\ > processor : 0 > vendor_id : GenuineIntel > processor : 1 > vendor_id : GenuineIntel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hyperthreading not working (?)... /proc/cpuinfo shows 2 cpus
HI I have just spent hours trying to figure this out, through google but no luck. I have a single pentium 4 w/ hyperthreading and am running kernel 2.6.13. I built my own kernel and enabled HT and the system seems to recognize two processors. Here is /proc/cpuinfo: /--\ processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 9 cpu MHz : 3000.571 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu 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 xtpr bogomips: 6008.35 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 9 cpu MHz : 3000.571 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu 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 xtpr bogomips: 6000.59 \/ But I can't find any sign that HT is working properly. Here is my /proc/interrupts file showing only one processor doing anything: /\ CPU0 CPU1 0: 830982 0IO-APIC-edge timer 1: 29760IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 12: 2119 0IO-APIC-edge i8042 14: 10163 0IO-APIC-edge ide0 15: 29646 0IO-APIC-edge ide1 16: 236276 0 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb4 17: 0 0 IO-APIC-level Intel ICH5, Intel ICH5 Modem 18: 0 0 IO-APIC-level uhci_hcd:usb3 19: 0 0 IO-APIC-level uhci_hcd:usb2 21: 3 0 IO-APIC-level ohci1394 22: 70223 0 IO-APIC-level eth0 23: 2 0 IO-APIC-level ehci_hcd:usb5 NMI: 0 0 LOC: 830932 830931 ERR: 0 MIS: 0 \---/ I believe I have all the necessary kernel options enabled but I may be doing something wrong. I saw some posts about including 'acpismp=force' to the boot parameters but I think these were for old 2.4 kernels. Thanks for your help, Brandon
Re: Hyperthreading
On Sat, 23 Jul 2005 12:13:05 -0500 "Andrew J. Fields" <[EMAIL PROTECTED]> wrote: > I am in the process of building a new computer, and was wondering if > Debian 3.1r0a is capable of running on a P4 3.2E Ghz processor with HT > Technology. Also, if the OS doesn't support HT, could it still work > anyway. Lastly, if this wont work, could you recommend any > distributions of Linux that support HT? Yes, Debian 3.1 will run fine both with and without HT support. To get HT support enabled, you will have to install a smp kernel - then the cpu will show up as 2 cpus. The installer does not install a smp enabled cpu, so you have to do it after the install is complete. HTH, Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hyperthreading
On 7/23/05, Andrew J. Fields <[EMAIL PROTECTED]> wrote: > I am in the process of building a new computer, and was wondering if Debian > 3.1r0a is capable of running on a P4 3.2E Ghz processor with HT Technology. > Also, if the OS doesn't support HT, could it still work anyway. Lastly, if > this wont work, could you recommend any distributions of Linux that support > HT? Any SMP kernel on Debian or virtually any other Linux distribution should work. On Debian, once you finish installing, you may need to manually install a kernel-image or linux-image package with `smp' in the name. I'm not sure whether the installer will do this for you - check with uname -a after installing.
Hyperthreading
I am in the process of building a new computer, and was wondering if Debian 3.1r0a is capable of running on a P4 3.2E Ghz processor with HT Technology. Also, if the OS doesn't support HT, could it still work anyway. Lastly, if this wont work, could you recommend any distributions of Linux that support HT? Thanks, AJ Fields <>
Re: Enabling hyperthreading
On Wed, 13 Oct 2004, Micha Feigin wrote: > I don't know enough about hyperthreading vs. real SMP but IIRC 2.6 > kernels are much better at smp then 2.4 They are extremely better at SMT (HyperThreading) than 2.4 kernels are. But HT works just fine on 2.4, I am typing this from a Intel D875PBZ with a 2.8GHz P4 HT. It just works much better on 2.6. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enabling hyperthreading
On Tue, Oct 12, 2004 at 02:49:19PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 13 Oct 2004, Paolo Alexis Falcone wrote: > > > I've got P4 3GHz Hyperthreading on Intel 865PERL > > > mainboard, > > > hyperthreading enable on BIOS. > > > I'm currently using sid 2.4.27 kernel with alsa > > > compiled. > > > I had tried to use 2.4.27-smp kernel and debian just > > > freeze at boot. > > > > This is weird behavior... nevertheless try disabling acpi and/or apic > > in the boot time parameters when you boot the SMP-enabled kernel and > > see what happens. > > Also, drop by the Intel site and make sure your board is running the latest > BIOS release. You should also download the errata for the manual and read > it. > I don't know enough about hyperthreading vs. real SMP but IIRC 2.6 kernels are much better at smp then 2.4 > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enabling hyperthreading
On Wed, 13 Oct 2004, Paolo Alexis Falcone wrote: > > I've got P4 3GHz Hyperthreading on Intel 865PERL > > mainboard, > > hyperthreading enable on BIOS. > > I'm currently using sid 2.4.27 kernel with alsa > > compiled. > > I had tried to use 2.4.27-smp kernel and debian just > > freeze at boot. > > This is weird behavior... nevertheless try disabling acpi and/or apic > in the boot time parameters when you boot the SMP-enabled kernel and > see what happens. Also, drop by the Intel site and make sure your board is running the latest BIOS release. You should also download the errata for the manual and read it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enabling hyperthreading
On Mon, 11 Oct 2004 13:41:13 +0800 (CST), ms linux <[EMAIL PROTECTED]> wrote: > I'm very sorry for asking the same question as I had > before. > But since googling doesn't help me much ( no luck I > guess or I'm just > too lazy ), I wonder if anybody here got good enough > how to to > enabling hyperthreading in my desktop debian. > I've got P4 3GHz Hyperthreading on Intel 865PERL > mainboard, > hyperthreading enable on BIOS. > I'm currently using sid 2.4.27 kernel with alsa > compiled. > I had tried to use 2.4.27-smp kernel and debian just > freeze at boot. This is weird behavior... nevertheless try disabling acpi and/or apic in the boot time parameters when you boot the SMP-enabled kernel and see what happens. -- Paolo Alexis Falcone [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Enabling hyperthreading
I'm very sorry for asking the same question as I had before. But since googling doesn't help me much ( no luck I guess or I'm just too lazy ), I wonder if anybody here got good enough how to to enabling hyperthreading in my desktop debian. I've got P4 3GHz Hyperthreading on Intel 865PERL mainboard, hyperthreading enable on BIOS. I'm currently using sid 2.4.27 kernel with alsa compiled. I had tried to use 2.4.27-smp kernel and debian just freeze at boot. Some url to point me to right direction will be very helpful. Thanks in advance. ---me--- __ Do You Yahoo!? Download the latest ringtones, games, and more! http://sg.mobile.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hyperthreading with 2.4.23 ?
Hi, has anyone got HT working with kernel 2.4.23? When I switched from 2.4.22, I lost HT on my Dual Xeon Servers (Serverworks chipset). I tried to google for some infos regarding the change and got several hits, but nothing really helped: tried to activate/deactivate ACPI in the kernel configs, tried several boot parameters: (acpismp=ht, acpismp=force) and greped the kernel sources for hyperthreading). Has anyone got HT working with 2.4.23? Thanks, Thomas here is one of my logs: (actually there are 4 procs found but only 2 activated) Dec 9 17:00:38 master05 kernel: ACPI: have wakeup address 0xc0002000 Dec 9 17:00:38 master05 kernel: found SMP MP-table at 000ff780 Dec 9 17:00:38 master05 kernel: hm, page 000ff000 reserved twice. Dec 9 17:00:38 master05 kernel: hm, page 0010 reserved twice. Dec 9 17:00:38 master05 kernel: hm, page 000f1000 reserved twice. Dec 9 17:00:38 master05 kernel: hm, page 000f2000 reserved twice. Dec 9 17:00:38 master05 kernel: On node 0 totalpages: 229376 Dec 9 17:00:38 master05 kernel: zone(0): 4096 pages. Dec 9 17:00:38 master05 kernel: zone(1): 225280 pages. Dec 9 17:00:38 master05 kernel: zone(2): 0 pages. Dec 9 17:00:38 master05 kernel: ACPI: RSDP (v000 INTEL ) @ 0x000ff9b0 Dec 9 17:00:38 master05 kernel: ACPI: RSDT (v001 INTEL SWV250x0001 MSFT 0x0100) @ 0x3fff Dec 9 17:00:38 master05 kernel: ACPI: FADT (v001 INTEL SWV250x0001 MSFT 0x0100) @ 0x3fff0030 Dec 9 17:00:38 master05 kernel: ACPI: MADT (v001 INTEL SWV250x0001 MSFT 0x0100) @ 0x3fff00b0 Dec 9 17:00:38 master05 kernel: ACPI: OEMR (v001 INTEL SWV250x0001 MSFT 0x0100) @ 0x3fff0140 Dec 9 17:00:38 master05 kernel: ACPI: DSDT (v001 INTELSWV25 0x0100 INTL 0x20020918) @ 0x Dec 9 17:00:38 master05 kernel: ACPI: Local APIC address 0xfee0 Dec 9 17:00:38 master05 kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Dec 9 17:00:38 master05 kernel: Processor #0 Pentium 4(tm) XEON(tm) APIC version 20 Dec 9 17:00:38 master05 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) Dec 9 17:00:38 master05 kernel: Processor #6 Pentium 4(tm) XEON(tm) APIC version 20 Dec 9 17:00:38 master05 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Dec 9 17:00:38 master05 kernel: Processor #1 Pentium 4(tm) XEON(tm) APIC version 20 Dec 9 17:00:38 master05 kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) Dec 9 17:00:38 master05 kernel: Processor #7 Pentium 4(tm) XEON(tm) APIC version 20 Dec 9 17:00:38 master05 kernel: ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x3] lint[0x1]) Dec 9 17:00:38 master05 kernel: ACPI: LAPIC_NMI (acpi_id[0x01] polarity[0x1] trigger[0x3] lint[0x1]) Dec 9 17:00:38 master05 kernel: Using ACPI (MADT) for SMP configuration information Dec 9 17:00:38 master05 kernel: Kernel command line: auto BOOT_IMAGE=linux root=900 acpi=force Dec 9 17:00:38 master05 kernel: Initializing CPU#0 Dec 9 17:00:38 master05 kernel: Detected 2392.344 MHz processor. Dec 9 17:00:38 master05 kernel: Console: colour VGA+ 80x25 Dec 9 17:00:38 master05 kernel: Calibrating delay loop... 4771.02 BogoMIPS Dec 9 17:00:38 master05 kernel: Memory: 904028k/917504k available (1876k kernel code, 13068k reserved, 762k data, 124k init, 0k highmem) Dec 9 17:00:38 master05 kernel: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Dec 9 17:00:38 master05 kernel: Inode cache hash table entries: 65536 (order: 7, 524288 bytes) Dec 9 17:00:38 master05 kernel: Mount cache hash table entries: 512 (order: 0, 4096 bytes) Dec 9 17:00:38 master05 kernel: Buffer cache hash table entries: 65536 (order: 6, 262144 bytes) Dec 9 17:00:38 master05 kernel: Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Dec 9 17:00:38 master05 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K Dec 9 17:00:38 master05 kernel: CPU: L2 cache: 512K Dec 9 17:00:38 master05 kernel: CPU: Physical Processor ID: 0 Dec 9 17:00:38 master05 kernel: CPU: After generic, caps: bfebfbff Dec 9 17:00:38 master05 kernel: CPU: Common caps: bfebfbff Dec 9 17:00:38 master05 kernel: Enabling fast FPU save and restore... done. Dec 9 17:00:38 master05 kernel: Enabling unmasked SIMD FPU exception support... done. Dec 9 17:00:38 master05 kernel: Checking 'hlt' instruction... OK. Dec 9 17:00:38 master05 kernel: POSIX conformance testing by UNIFIX Dec 9 17:00:38 master05 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K Dec 9 17:00:38 master05 kernel: CPU: L2 cache: 512K Dec 9 17:00:38 master05 kernel: CPU: Physical Processor ID: 0 Dec 9 17:00:38 master05 kernel: CPU: After generic, caps: bfebfbff Dec 9 17:00:38 master05 kernel: CPU: Common caps: bfebfbff Dec 9 17:00:38 master05 kernel: CPU0: Intel(R) Xeon(TM) C
Help: Xfree and P4 with hyperthreading - CRASH
Hello debian-user, I have installed a Debian Woody with a 2.4.22 kernel taken from Debian unstable on a Intel 865 mainboard with a Pentium4 processor with hyperthreading support. The kernel is configured as SMP and it can see the two "virtual" processors correctly. Everything works but X crashes the PC completely, when it starts or when it stops, randomly. I have a Matrox G400 card, with agpgart and mga support compiled as modules. I have tried also disabling DRM, unloading modules, and running X. It still crashes. I have searched google and found absolutely nothing, not only one person having the same problem I am experiencing. Can someone help? Does someone have a similar configuration running (or crashing like mine)? Thanks a lot. -- Fabio "Kurgan" Muzzi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
On Mon, 2003-09-29 at 14:42, Sindre wrote: > > The BIOS is pre-OS, so that logo must be displayed by Windows. > > Your facts are right, but your conclusion is wrong, the bios is actually aware > if the last booted OS did use smp or not. > My quad cpu compaq report 3 of the cpus as failed if I reboot after using a > non-smp kernel, or 2 failed if I last booted windows. > I guess the same could happen on a p4 HT. Yup, just as I was thinking. I'll find out for definite by tonight when I enable HT in Linux. If I can then reboot Debian and get the "HT" P4 logo, then that will be it. Regards, Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
On Mon, 2003-09-29 at 14:29, Ron Johnson wrote: > On Mon, 2003-09-29 at 07:59, Andrew Ingram wrote: > > On Mon, 2003-09-29 at 13:19, Greg Norris wrote: > > > On Mon, Sep 29, 2003 at 12:09:18PM +0100, Andrew Ingram wrote: > [snip] > > Sounds easy enough! Might explain why my BIOS logo doesn't sport the > > "HT" after a reboot of Linux, but does after a reboot of Win XP (which > > recognises 2 CPUs). > > The BIOS is pre-OS, so that logo must be displayed by Windows. That would make sense, but this logo is the BIOS full screen logo for the mobo. It's a picture of an outline of a person's head, with ASUS P4P800 Deluxe (the mobo) written beneath, and an Intel P4 logo in the bottom right hand corner. What I have discovered is that if the last reboot was from XP, I get the P4 with the "HT" logo, if Linux (or Win98) were the last booted, I get the same screen, with just a normal P4 logo (without the HT). This is all from the BIOS, before even the IDE is detected so it can't be windows interfering. I dont know how it works out what to display, but it's curious. I wonder if the BIOS maybe stores something in CMOS to say whether HT was used in the last session? Just a guess. Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
> The BIOS is pre-OS, so that logo must be displayed by Windows. Your facts are right, but your conclusion is wrong, the bios is actually aware if the last booted OS did use smp or not. My quad cpu compaq report 3 of the cpus as failed if I reboot after using a non-smp kernel, or 2 failed if I last booted windows. I guess the same could happen on a p4 HT. - Sindre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
On Mon, 2003-09-29 at 07:59, Andrew Ingram wrote: > On Mon, 2003-09-29 at 13:19, Greg Norris wrote: > > On Mon, Sep 29, 2003 at 12:09:18PM +0100, Andrew Ingram wrote: [snip] > Sounds easy enough! Might explain why my BIOS logo doesn't sport the > "HT" after a reboot of Linux, but does after a reboot of Win XP (which > recognises 2 CPUs). The BIOS is pre-OS, so that logo must be displayed by Windows. -- - Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "You ask us the same question every day, and we give you the same answer every day. Someday, we hope that you will believe us..." U.S. Secretary of Defense Donald Rumsfeld, to a reporter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
On Mon, 2003-09-29 at 13:19, Greg Norris wrote: > On Mon, Sep 29, 2003 at 12:09:18PM +0100, Andrew Ingram wrote: > > Can anyone tell me if there is anything special I should enable in my > > kernel (or any other Debian configuration) to make the most out of an > > Intel P4 processor with HyperThreading? Just realised my kernel has SMP > > disabled which might have been a mistake, but I can't find a definitive > > answer by googling. > > You need to enable SMP, and also ACPI CPU Enumeration... either > CONFIG_ACPI_HT_ONLY or CONFIG_ACPI_PROCESSOR. In the former case, you > may also need to use the boot parameter "acpismp=force". If memory > serves, it's no longer required as of 2.4.22. Thanks for the responses guys. I'm running 2.4.22. So if I understand you right, I need to enable SMP, and also CONFIG_ACPI_HT_ONLY or CONFIG_ACPI_PROCESSOR (I assume only one of these will actually be available). Sounds easy enough! Might explain why my BIOS logo doesn't sport the "HT" after a reboot of Linux, but does after a reboot of Win XP (which recognises 2 CPUs). Thanks, Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
On Mon, 29 Sep 2003, Greg Norris wrote: > On Mon, Sep 29, 2003 at 12:09:18PM +0100, Andrew Ingram wrote: > > Can anyone tell me if there is anything special I should enable in my > > kernel (or any other Debian configuration) to make the most out of an > > Intel P4 processor with HyperThreading? Just realised my kernel has SMP > > disabled which might have been a mistake, but I can't find a definitive > > answer by googling. > > You need to enable SMP, and also ACPI CPU Enumeration... either > CONFIG_ACPI_HT_ONLY or CONFIG_ACPI_PROCESSOR. In the former case, you > may also need to use the boot parameter "acpismp=force". If memory > serves, it's no longer required as of 2.4.22. And, even if it sound stupid: enable hyperthreading in the bios. Gaspard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HyperThreading CPUs under Debian
On Mon, Sep 29, 2003 at 12:09:18PM +0100, Andrew Ingram wrote: > Can anyone tell me if there is anything special I should enable in my > kernel (or any other Debian configuration) to make the most out of an > Intel P4 processor with HyperThreading? Just realised my kernel has SMP > disabled which might have been a mistake, but I can't find a definitive > answer by googling. You need to enable SMP, and also ACPI CPU Enumeration... either CONFIG_ACPI_HT_ONLY or CONFIG_ACPI_PROCESSOR. In the former case, you may also need to use the boot parameter "acpismp=force". If memory serves, it's no longer required as of 2.4.22. signature.asc Description: Digital signature
Re: HyperThreading CPUs under Debian
Andrew Ingram wrote: Can anyone tell me if there is anything special I should enable in my kernel (or any other Debian configuration) to make the most out of an Intel P4 processor with HyperThreading? Just realised my kernel has SMP disabled which might have been a mistake, but I can't find a definitive answer by googling. Yes, you should have SMP enabled and the kernel will detect 2 CPUs. I'm using 2.4.21. Cheers, Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
HyperThreading CPUs under Debian
Can anyone tell me if there is anything special I should enable in my kernel (or any other Debian configuration) to make the most out of an Intel P4 processor with HyperThreading? Just realised my kernel has SMP disabled which might have been a mistake, but I can't find a definitive answer by googling. Thanks, Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and Intel's Hyperthreading
On Sat, 2003-01-04 at 21:13, Rob Weir wrote: > On Thu, Jan 02, 2003 at 07:35:41PM +0100, mess-mate wrote: > > On Tue, 31 Dec 2002 20:16:03 -0800 (PST) > > "nate" <[EMAIL PROTECTED]> wrote: > > > > | nick lidakis said: [snip] > > Well, ASUS suggest to compile with the Hyper-Threading compiler ??? > > What about this compiler ? > > I'd say they mean Intel's non-Free C/C++ compiler. It costs a bucket in > general, but I think it's free (as in beer) for personal use. Of > course, the C++ compiler's ABI is incompatible with every GCC release > thus far (not that GCC is even compatible with itself, across releases), > so you'll have a hell of a time getting it to integrate int your Debian > system, if you decide to use it. Depending on what you do, it can > apparently lead to enormous speedups (mostly with numerical code > though, or so I hear), but GCC 3.x is closing the gap... > > Anyhow, I can't imagine that a smart compiler could do *that* much to > help, since getting good performance on multi-processor systems is more > of a programming design issue, rather than compiler smarts. No doubt > having two 'CPU's in the once chip, sharing registers and cache requires > some compiler intelligence though. You'd be amazed at how good those ex-DEC compiler writers are... http://www.coyotegulch.com/reviews/almabench.html In this heavily numerical benchmark, the best Intel Fortran and C++ timings are 3.24x faster than the best g++ 3.2.1 timings. -- ++ | Ron Johnson, Jr. mailto:[EMAIL PROTECTED] | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | || | "Basically, I got on the plane with a bomb. Basically, I | | tried to ignite it. Basically, yeah, I intended to damage | | the plane." | |RICHARD REID, who tried to blow up American Airlines| | Flight 63 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and Intel's Hyperthreading
On Thu, Jan 02, 2003 at 07:35:41PM +0100, mess-mate wrote: > On Tue, 31 Dec 2002 20:16:03 -0800 (PST) > "nate" <[EMAIL PROTECTED]> wrote: > > | nick lidakis said: > | > I was looking to replace my 1Ghz P3 and motherboard with a stable, but > | > fast mb/cpu combo that was fully supported by a recent linux kernel. I > | > was looking a an Intel 845PE motherboard with a 3.0Ghz cpu. My question > | > is, how is Hyperthreading supported under linux? Is it a matter of > | > enabling SMP in the kernel? Anyone playing with one of these CPU's? > | > | > | it is supported by default. the system will see double the cpus there > | actually are. the kernel isn't tuned to fully take advantage of the > | hyperthreading yet though. I think newer 2.5.x kernels can do it, perhaps > | theres a patch for 2.4.x.. but last I read the current breed of stable > | kernels are not optimized for it. > | > | If I had a system with hyperthreading I would disable the hyperthreading > | in the bios(one mailing list thread mentioned there is an option to do > | so, at least on some systems). Because the kernel would get confused and > | think there are 4 processors on a 2 processor system it might try to get > | smart by loading stuff up on processor #2, not knowing its the same physical > | processor as #1, before loading stuff on #3. I don't remember any benchmark > | numbers but I seem to recall there being very little if any difference > | in performance on hyperthreaded systems with hyperthreading on vs. off > | on the stock kernels(performance can go way up on the newer 2.5.x which > | are tuned to take advantage of it in some cases). > | > | I've read one post on the redhat list recently, some guy was asking why > | top showed 4 cpus on his dual p4, since it was a dual cpu system, a guy > | responded because it was hyperthreading ... > | > | so it should work, just not very optimal. > | > | nate > | > Well, ASUS suggest to compile with the Hyper-Threading compiler ??? > What about this compiler ? I'd say they mean Intel's non-Free C/C++ compiler. It costs a bucket in general, but I think it's free (as in beer) for personal use. Of course, the C++ compiler's ABI is incompatible with every GCC release thus far (not that GCC is even compatible with itself, across releases), so you'll have a hell of a time getting it to integrate int your Debian system, if you decide to use it. Depending on what you do, it can apparently lead to enormous speedups (mostly with numerical code though, or so I hear), but GCC 3.x is closing the gap... Anyhow, I can't imagine that a smart compiler could do *that* much to help, since getting good performance on multi-processor systems is more of a programming design issue, rather than compiler smarts. No doubt having two 'CPU's in the once chip, sharing registers and cache requires some compiler intelligence though. -rob msg22510/pgp0.pgp Description: PGP signature
Re: Linux and Intel's Hyperthreading
On Tue, 31 Dec 2002 20:16:03 -0800 (PST) "nate" <[EMAIL PROTECTED]> wrote: | nick lidakis said: | > I was looking to replace my 1Ghz P3 and motherboard with a stable, but | > fast mb/cpu combo that was fully supported by a recent linux kernel. I | > was looking a an Intel 845PE motherboard with a 3.0Ghz cpu. My question | > is, how is Hyperthreading supported under linux? Is it a matter of | > enabling SMP in the kernel? Anyone playing with one of these CPU's? | | | it is supported by default. the system will see double the cpus there | actually are. the kernel isn't tuned to fully take advantage of the | hyperthreading yet though. I think newer 2.5.x kernels can do it, perhaps | theres a patch for 2.4.x.. but last I read the current breed of stable | kernels are not optimized for it. | | If I had a system with hyperthreading I would disable the hyperthreading | in the bios(one mailing list thread mentioned there is an option to do | so, at least on some systems). Because the kernel would get confused and | think there are 4 processors on a 2 processor system it might try to get | smart by loading stuff up on processor #2, not knowing its the same physical | processor as #1, before loading stuff on #3. I don't remember any benchmark | numbers but I seem to recall there being very little if any difference | in performance on hyperthreaded systems with hyperthreading on vs. off | on the stock kernels(performance can go way up on the newer 2.5.x which | are tuned to take advantage of it in some cases). | | I've read one post on the redhat list recently, some guy was asking why | top showed 4 cpus on his dual p4, since it was a dual cpu system, a guy | responded because it was hyperthreading ... | | so it should work, just not very optimal. | | nate | Well, ASUS suggest to compile with the Hyper-Threading compiler ??? What about this compiler ? Thanks mess-mate -- Computers are like air conditioners, they are useless when you open Windows. msg21999/pgp0.pgp Description: PGP signature
Re: Linux and Intel's Hyperthreading
nick lidakis said: > I was looking to replace my 1Ghz P3 and motherboard with a stable, but > fast mb/cpu combo that was fully supported by a recent linux kernel. I > was looking a an Intel 845PE motherboard with a 3.0Ghz cpu. My question > is, how is Hyperthreading supported under linux? Is it a matter of > enabling SMP in the kernel? Anyone playing with one of these CPU's? it is supported by default. the system will see double the cpus there actually are. the kernel isn't tuned to fully take advantage of the hyperthreading yet though. I think newer 2.5.x kernels can do it, perhaps theres a patch for 2.4.x.. but last I read the current breed of stable kernels are not optimized for it. If I had a system with hyperthreading I would disable the hyperthreading in the bios(one mailing list thread mentioned there is an option to do so, at least on some systems). Because the kernel would get confused and think there are 4 processors on a 2 processor system it might try to get smart by loading stuff up on processor #2, not knowing its the same physical processor as #1, before loading stuff on #3. I don't remember any benchmark numbers but I seem to recall there being very little if any difference in performance on hyperthreaded systems with hyperthreading on vs. off on the stock kernels(performance can go way up on the newer 2.5.x which are tuned to take advantage of it in some cases). I've read one post on the redhat list recently, some guy was asking why top showed 4 cpus on his dual p4, since it was a dual cpu system, a guy responded because it was hyperthreading ... so it should work, just not very optimal. nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Linux and Intel's Hyperthreading
I was looking to replace my 1Ghz P3 and motherboard with a stable, but fast mb/cpu combo that was fully supported by a recent linux kernel. I was looking a an Intel 845PE motherboard with a 3.0Ghz cpu. My question is, how is Hyperthreading supported under linux? Is it a matter of enabling SMP in the kernel? Anyone playing with one of these CPU's? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
