* Re: TSCs are a no-no on i386
@ 2003-08-06 16:45 James Bottomley
0 siblings, 0 replies; 35+ messages in thread
From: James Bottomley @ 2003-08-06 16:45 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Linux Kernel
> And I think the i82489DX APIC was introduced a bit later
> anyway -- we don't support non-APIC SMP implementations.
Actually, we do in 2.6 for 486, 586 and PPro.
James
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386
@ 2003-08-06 16:41 James Bottomley
0 siblings, 0 replies; 35+ messages in thread
From: James Bottomley @ 2003-08-06 16:41 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linux Kernel
> Hopefully there are not too many SMP-486 machines out there ;-).
The mach-voyager subarchitecture code in 2.6 is designed to be able to
boot an SMP 486 system. I actually have (or rather have the cards to
build) a 5-way 486 system. (Although the cpu's were all certified as
having correct cmpxchg semantics).
James
^ permalink raw reply [flat|nested] 35+ messages in thread
* TSCs are a no-no on i386 @ 2003-07-30 13:56 Jan-Benedict Glaw 2003-07-30 14:18 ` Maciej W. Rozycki ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 13:56 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Hi! This small patch fixes a long-standing problem for bare i386 CPUs. These don't have TSCs and so, a recent 2.4.x kernel will simply halt the machine leaving a text like "This CPU has no TSC feature (ie was compiled for Pentium+) but I do depend on it". Please apply. Worst to say, even Debian seems to start using i486+ features (ie. libstdc++5 is SIGILLed on Am386 because there's no "lock" insn available)... MfG, JBG --- linux-2.4.22-pre9/arch/i386/config.in.orig 2003-07-30 15:00:27.000000000 +0200 +++ linux-2.4.22-pre9/arch/i386/config.in 2003-07-30 15:01:56.000000000 +0200 @@ -56,6 +56,7 @@ define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n define_bool CONFIG_X86_PPRO_FENCE y define_bool CONFIG_X86_F00F_WORKS_OK n + define_bool CONFIG_X86_HAS_TSC n else define_bool CONFIG_X86_WP_WORKS_OK y define_bool CONFIG_X86_INVLPG y -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 13:56 Jan-Benedict Glaw @ 2003-07-30 14:18 ` Maciej W. Rozycki 2003-07-30 14:44 ` Jan-Benedict Glaw 2003-07-30 16:58 ` Matthew Garrett 2003-07-30 18:10 ` Adrian Bunk 2 siblings, 1 reply; 35+ messages in thread From: Maciej W. Rozycki @ 2003-07-30 14:18 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: Marcelo Tosatti, lkml On Wed, 30 Jul 2003, Jan-Benedict Glaw wrote: > This small patch fixes a long-standing problem for bare i386 CPUs. These > don't have TSCs and so, a recent 2.4.x kernel will simply halt the Actually i486 processors and some Pentium-like clones have none, too. > machine leaving a text like "This CPU has no TSC feature (ie was > compiled for Pentium+) but I do depend on it". That only happens if you change existing .config -- it may happen for all options that are unset instead of being set to "n" -- and it can be worked around by running `make oldconfig' twice. > Please apply. Worst to say, even Debian seems to start using i486+ > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > "lock" insn available)... You need the change for CONFIG_M486 and CONFIG_M586 as well. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 14:18 ` Maciej W. Rozycki @ 2003-07-30 14:44 ` Jan-Benedict Glaw 0 siblings, 0 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 14:44 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Marcelo Tosatti, lkml [-- Attachment #1: Type: text/plain, Size: 1798 bytes --] On Wed, 2003-07-30 16:18:11 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl> wrote in message <Pine.GSO.3.96.1030730161309.911E-100000@delta.ds2.pg.gda.pl>: > On Wed, 30 Jul 2003, Jan-Benedict Glaw wrote: > > This small patch fixes a long-standing problem for bare i386 CPUs. These > > don't have TSCs and so, a recent 2.4.x kernel will simply halt the > > Actually i486 processors and some Pentium-like clones have none, too. Ah, I didn't know that. Here's the updated patch: --- linux-2.4.22-pre9/arch/i386/config.in.orig 2003-07-30 16:38:03.000000000 +0200 +++ linux-2.4.22-pre9/arch/i386/config.in 2003-07-30 16:39:20.000000000 +0200 @@ -56,6 +56,7 @@ define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n define_bool CONFIG_X86_PPRO_FENCE y define_bool CONFIG_X86_F00F_WORKS_OK n + define_bool CONFIG_X86_HAS_TSC n else define_bool CONFIG_X86_WP_WORKS_OK y define_bool CONFIG_X86_INVLPG y @@ -72,6 +73,7 @@ define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_PPRO_FENCE y define_bool CONFIG_X86_F00F_WORKS_OK n + define_bool CONFIG_X86_HAS_TSC n fi if [ "$CONFIG_M586" = "y" ]; then define_int CONFIG_X86_L1_CACHE_SHIFT 5 @@ -79,6 +81,7 @@ define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_PPRO_FENCE y define_bool CONFIG_X86_F00F_WORKS_OK n + define_bool CONFIG_X86_HAS_TSC n fi if [ "$CONFIG_M586TSC" = "y" ]; then define_int CONFIG_X86_L1_CACHE_SHIFT 5 MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 13:56 Jan-Benedict Glaw 2003-07-30 14:18 ` Maciej W. Rozycki @ 2003-07-30 16:58 ` Matthew Garrett 2003-07-30 17:19 ` Alan Cox 2003-07-30 18:10 ` Adrian Bunk 2 siblings, 1 reply; 35+ messages in thread From: Matthew Garrett @ 2003-07-30 16:58 UTC (permalink / raw) To: lkml Jan-Benedict Glaw wrote: >Please apply. Worst to say, even Debian seems to start using i486+ >features (ie. libstdc++5 is SIGILLed on Am386 because there's no >"lock" insn available)... g++ >=3.2 use 486-specific instructions in order to do atomic operations in C++ code. 3.3 includes a 386 version of the same code, but it's not possible to use a mixture of the two (ie, code compiled with a "486" g++ will not work on the "386" version), and so to keep ABI compatibility with the other distributions it's necessary to break 386. The "obvious" solution (dragging this back on topic) is a kernel patch to emulate 486 instructions on a 386. -- Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 16:58 ` Matthew Garrett @ 2003-07-30 17:19 ` Alan Cox 0 siblings, 0 replies; 35+ messages in thread From: Alan Cox @ 2003-07-30 17:19 UTC (permalink / raw) To: Matthew Garrett; +Cc: lkml On Mer, 2003-07-30 at 17:58, Matthew Garrett wrote: > g++ >=3.2 use 486-specific instructions in order to do atomic operations > in C++ code. 3.3 includes a 386 version of the same code, but it's not > possible to use a mixture of the two (ie, code compiled with a "486" g++ > will not work on the "386" version), and so to keep ABI compatibility > with the other distributions it's necessary to break 386. The "obvious" > solution (dragging this back on topic) is a kernel patch to emulate 486 > instructions on a 386. You don't need to mash the kernel up for this - you can write yourself a SIGILL handler to do the work - take a look at things like the pure software MMX preloader someone wrote. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 13:56 Jan-Benedict Glaw 2003-07-30 14:18 ` Maciej W. Rozycki 2003-07-30 16:58 ` Matthew Garrett @ 2003-07-30 18:10 ` Adrian Bunk 2003-07-30 18:30 ` Mike Fedyk 2003-07-30 20:27 ` Jan-Benedict Glaw 2 siblings, 2 replies; 35+ messages in thread From: Adrian Bunk @ 2003-07-30 18:10 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: >... > Please apply. Worst to say, even Debian seems to start using i486+ > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > "lock" insn available)... Shouldn't the 486 emulation in the latest 386 kernel images in Debian unstable take care of this? > MfG, JBG >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:10 ` Adrian Bunk @ 2003-07-30 18:30 ` Mike Fedyk 2003-07-30 18:45 ` Adrian Bunk 2003-07-30 20:27 ` Jan-Benedict Glaw 1 sibling, 1 reply; 35+ messages in thread From: Mike Fedyk @ 2003-07-30 18:30 UTC (permalink / raw) To: Adrian Bunk; +Cc: lkml On Wed, Jul 30, 2003 at 08:10:06PM +0200, Adrian Bunk wrote: > On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: > >... > > Please apply. Worst to say, even Debian seems to start using i486+ > > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > > "lock" insn available)... > > Shouldn't the 486 emulation in the latest 386 kernel images in Debian > unstable take care of this? What emulation? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:30 ` Mike Fedyk @ 2003-07-30 18:45 ` Adrian Bunk 2003-07-30 20:01 ` Alan Cox 2003-07-30 20:28 ` Jan-Benedict Glaw 0 siblings, 2 replies; 35+ messages in thread From: Adrian Bunk @ 2003-07-30 18:45 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 11:30:33AM -0700, Mike Fedyk wrote: > On Wed, Jul 30, 2003 at 08:10:06PM +0200, Adrian Bunk wrote: > > On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: > > >... > > > Please apply. Worst to say, even Debian seems to start using i486+ > > > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > > > "lock" insn available)... > > > > Shouldn't the 486 emulation in the latest 386 kernel images in Debian > > unstable take care of this? > > What emulation? 486 emulation CONFIG_CPU_EMU486 When used on a 386, Linux can emulate 3 instructions from the 486 set. This allows user space programs compiled for 486 to run on a 386 without crashing with a SIGILL. As any emulation, performance will be very low, but since these instruction are not often used, this might not hurt. The emulated instructions are: - bswap (does the same as htonl()) - cmpxchg (used in multi-threading, mutex locking) - xadd (rarely used) Note that this can also allow Step-A 486's to correctly run multi-thread applications since cmpxchg has a wrong opcode on this early CPU. Don't use this to enable multi-threading on an SMP machine, the lock atomicity can't be guaranted! Although it's highly preferable that you only execute programs targetted for your CPU, it may happen that, consecutively to a hardware replacement, or during rescue of a damaged system, you have to execute such programs on an inadapted processor. In this case, this option will help you get your programs working, even if they will be slower. It is recommended that you say N here in any case, except for the kernels that you will use on your rescue disks. This option should not be left on by default, because it means that you execute a program not targetted for your CPU. You should recompile your applications whenever possible. If you are not sure, say N. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:45 ` Adrian Bunk @ 2003-07-30 20:01 ` Alan Cox 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-08-06 11:08 ` Pavel Machek 2003-07-30 20:28 ` Jan-Benedict Glaw 1 sibling, 2 replies; 35+ messages in thread From: Alan Cox @ 2003-07-30 20:01 UTC (permalink / raw) To: Adrian Bunk; +Cc: lkml On Mer, 2003-07-30 at 19:45, Adrian Bunk wrote: > Note that this can also allow Step-A 486's to correctly run multi-thread > applications since cmpxchg has a wrong opcode on this early CPU. > > Don't use this to enable multi-threading on an SMP machine, the lock > atomicity can't be guaranted! That is of course the other problem with this approach - you can't really get the intended results without some extremely heavyweight code (using an IPI to halt all CPU's, doing the access and then resuming them) The bigger problem (and certainly with some of the cmov emulation hacks I've seen) is getting the security checking right when you need to reprocess the user data - another reason to do it in userspace with a preload 8) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:01 ` Alan Cox @ 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-07-30 22:19 ` J.A. Magallon ` (2 more replies) 2003-08-06 11:08 ` Pavel Machek 1 sibling, 3 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 20:33 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1640 bytes --] On Wed, 2003-07-30 21:01:00 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote in message <1059595260.10447.6.camel@dhcp22.swansea.linux.org.uk>: > On Mer, 2003-07-30 at 19:45, Adrian Bunk wrote: > > Note that this can also allow Step-A 486's to correctly run multi-thread > > applications since cmpxchg has a wrong opcode on this early CPU. > > > > Don't use this to enable multi-threading on an SMP machine, the lock > > atomicity can't be guaranted! > > The bigger problem (and certainly with some of the cmov emulation hacks > I've seen) is getting the security checking right when you need to > reprocess the user data - another reason to do it in userspace with a > preload 8) Well... For sure, I can write a LD_PRELOAD lib dealing with SIGILL, but how do I enable it for the whole system. That is, I'd need to give LD_PRELOAD=xxx at the kernel's boot prompt to have it as en environment variable for each and every process? That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ be compiled for i386 ... ...and IFF those new opcodes bring _that_ much performance, then we should think about another Debian distribution for i686-linux. Up to now, I was really proud of having _one_ distribution that's basically capable of running on all and any machines I own... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:33 ` Jan-Benedict Glaw @ 2003-07-30 22:19 ` J.A. Magallon 2003-07-31 6:11 ` Jan-Benedict Glaw 2003-07-30 23:05 ` Alan Cox 2003-07-31 0:22 ` Adrian Bunk 2 siblings, 1 reply; 35+ messages in thread From: J.A. Magallon @ 2003-07-30 22:19 UTC (permalink / raw) To: linux-kernel On 07.30, Jan-Benedict Glaw wrote: [...] > > ...and IFF those new opcodes bring _that_ much performance, then we > should think about another Debian distribution for i686-linux. Up to > now, I was really proud of having _one_ distribution that's basically > capable of running on all and any machines I own... > Do as Mandrake (and I suppose another distros), and put optimized libraries in /lib/i686, /lib/mmx, /lib/sse, /usr/lib/i686, etc. New ld.so supports mapping different versions of library depending on arch. -- J.A. Magallon <jamagallon@able.es> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.22-pre9-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-0.7mdk)) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 22:19 ` J.A. Magallon @ 2003-07-31 6:11 ` Jan-Benedict Glaw 0 siblings, 0 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 6:11 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1444 bytes --] On Thu, 2003-07-31 00:19:25 +0200, J.A. Magallon <jamagallon@able.es> wrote in message <20030730221925.GA2858@werewolf.able.es>: > On 07.30, Jan-Benedict Glaw wrote: > [...] > > ...and IFF those new opcodes bring _that_ much performance, then we > > should think about another Debian distribution for i686-linux. Up to > > now, I was really proud of having _one_ distribution that's basically > > capable of running on all and any machines I own... > > Do as Mandrake (and I suppose another distros), and put optimized libraries > in /lib/i686, /lib/mmx, /lib/sse, /usr/lib/i686, etc. New ld.so supports > mapping different versions of library depending on arch. I know. ...and this won't work. Think about this: - Some lib links (statically) some parts of libstdc++5.a. This is done on a i386. - Some app (compiled for i486 on some other box) links against the above lib (which was copied over). Now, you've got two ways to access your atomic variables. Do that multithreaded, and you'll boom. It's all about "eventually" and "possibly", but you break binary compatibility at some point. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-07-30 22:19 ` J.A. Magallon @ 2003-07-30 23:05 ` Alan Cox 2003-07-31 11:11 ` Richard B. Johnson 2003-07-31 11:41 ` Jan-Benedict Glaw 2003-07-31 0:22 ` Adrian Bunk 2 siblings, 2 replies; 35+ messages in thread From: Alan Cox @ 2003-07-30 23:05 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: lkml On Mer, 2003-07-30 at 21:33, Jan-Benedict Glaw wrote: > Well... For sure, I can write a LD_PRELOAD lib dealing with SIGILL, but > how do I enable it for the whole system. That is, I'd need to give > LD_PRELOAD=xxx at the kernel's boot prompt to have it as en environment > variable for each and every process? /etc/ld.preload > That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ > be compiled for i386 ... True ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 23:05 ` Alan Cox @ 2003-07-31 11:11 ` Richard B. Johnson 2003-07-31 11:41 ` Jan-Benedict Glaw 1 sibling, 0 replies; 35+ messages in thread From: Richard B. Johnson @ 2003-07-31 11:11 UTC (permalink / raw) To: Alan Cox; +Cc: Jan-Benedict Glaw, lkml On Wed, 31 Jul 2003, Alan Cox wrote: > On Mer, 2003-07-30 at 21:33, Jan-Benedict Glaw wrote: > > Well... For sure, I can write a LD_PRELOAD lib dealing with SIGILL, but > > how do I enable it for the whole system. That is, I'd need to give > > LD_PRELOAD=xxx at the kernel's boot prompt to have it as en environment > > variable for each and every process? > > > /etc/ld.preload > > > That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ > > be compiled for i386 ... > > True > What is a runtime library doing with a TSC? That's the basic problem. These things are for operating systems and, last time I checked, the 'C' runtime libraries weren't (but maybe GNU changed that definition, no?) Cheers, Dick Johnson Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 23:05 ` Alan Cox 2003-07-31 11:11 ` Richard B. Johnson @ 2003-07-31 11:41 ` Jan-Benedict Glaw 1 sibling, 0 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 11:41 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 867 bytes --] On Thu, 2003-07-31 00:05:53 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote in message <1059606259.10505.20.camel@dhcp22.swansea.linux.org.uk>: > On Mer, 2003-07-30 at 21:33, Jan-Benedict Glaw wrote: > > Well... For sure, I can write a LD_PRELOAD lib dealing with SIGILL, but > > how do I enable it for the whole system. That is, I'd need to give > > LD_PRELOAD=xxx at the kernel's boot prompt to have it as en environment > > variable for each and every process? > > /etc/ld.preload /etc/ld.so.preload, that is. Only for the records:) MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-07-30 22:19 ` J.A. Magallon 2003-07-30 23:05 ` Alan Cox @ 2003-07-31 0:22 ` Adrian Bunk 2003-07-31 6:22 ` Jan-Benedict Glaw 2 siblings, 1 reply; 35+ messages in thread From: Adrian Bunk @ 2003-07-31 0:22 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 10:33:18PM +0200, Jan-Benedict Glaw wrote: >... > That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ > be compiled for i386 ... > > ...and IFF those new opcodes bring _that_ much performance, then we > should think about another Debian distribution for i686-linux. Up to > now, I was really proud of having _one_ distribution that's basically > capable of running on all and any machines I own... The 486 emlation patch for 386 is the way to still allow 386's to run Debian. To compile libstdc++ for 486 wasn't a performance question - a libstdc++.so.5 compiled for 386 would have meant that C++ binaries compiled on Debian wouldn't run on other Linux distributions and vice versa [1] (it's a bug in libstdc++ that will AFAIR be fixed in gcc 3.4). > MfG, JBG cu Adrian [1] http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 0:22 ` Adrian Bunk @ 2003-07-31 6:22 ` Jan-Benedict Glaw 2003-07-31 7:17 ` Willy Tarreau 0 siblings, 1 reply; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 6:22 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1691 bytes --] On Thu, 2003-07-31 02:22:31 +0200, Adrian Bunk <bunk@fs.tum.de> wrote in message <20030731002230.GE22991@fs.tum.de>: > On Wed, Jul 30, 2003 at 10:33:18PM +0200, Jan-Benedict Glaw wrote: > >... > > That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ > > be compiled for i386 ... > > > > ...and IFF those new opcodes bring _that_ much performance, then we > > should think about another Debian distribution for i686-linux. Up to > > now, I was really proud of having _one_ distribution that's basically > > capable of running on all and any machines I own... > > The 486 emlation patch for 386 is the way to still allow 386's to run > Debian. Okay, I'll have a look at it. Where's the 2.6.x version? > To compile libstdc++ for 486 wasn't a performance question - a > libstdc++.so.5 compiled for 386 would have meant that C++ binaries > compiled on Debian wouldn't run on other Linux distributions and vice > versa [1] (it's a bug in libstdc++ that will AFAIR be fixed in gcc 3.4). I've got no idea when this version will come up. What's the (Debian) timeline for a gcc-3.4 based libstdc++ then? I've already tried gcc-snapshot's libstdc++, but that's libstdc++6, which won't link with todays applications... Well, it's not only that. Seen the thread named like "Time loss on i486"? That'll be some fun, too:) Itching my head, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 6:22 ` Jan-Benedict Glaw @ 2003-07-31 7:17 ` Willy Tarreau 2003-07-31 15:07 ` Jamie Lokier 0 siblings, 1 reply; 35+ messages in thread From: Willy Tarreau @ 2003-07-31 7:17 UTC (permalink / raw) To: lkml On Thu, Jul 31, 2003 at 08:22:52AM +0200, Jan-Benedict Glaw wrote: > > The 486 emlation patch for 386 is the way to still allow 386's to run > > Debian. > > Okay, I'll have a look at it. Where's the 2.6.x version? It doesn't exist, but could certainly easily be ported from 2.4. But I think that people want to use it the wrong way. I wrote it to allow older machines to *occasionally* run code designed for the wrong architecture. Eg, your machine dies, you unplug the disk and puts it in another one, a smaller one, and cross your fingers for the system to work again. In this case, I think it's easier to compile a kernel with the right options to allow emulation than to reinstall the system with the proper packages. Now it seems to me that people want to use it as an excuse not to respect architectural constraints and processors instructions sets. Of course, it's easy to compile everything for i686 and think "well, if the machine doesn't support this or that, then the kernel will do...". But you quickly end up in even more slowing down small machines. The other problem lies with the lock : When a 486 executes "LOCK ; CMPXCHG", it locks the bus during the whole cmpxchg instruction. If a 386 executes the same code, it will get an exception which will be caught by the emulator. I don't see how we can do such an atomic operation while holding a lock. At best, we would think about a global memory based shared lock during the operation (eg: int bus_lock;), but it's not implemented at the moment, and will only be compatible with processors sharing the same code. Add-on processors, such as co-processors, transputer cards, or DSPs, will know nothing about such a lock emulation. And it would result in even poorer performance of course ! And yes, I've done intensive benchmarks on the code, as did Denis Vladensko. I used it daily on my 386sx firewall, which avoided me to recompile my pppd for this architecture... At this time, I had a wrong gcc+libc combinations and always got BSWAP instructions all over the code. Although pppd did not suffer from emulation, I have seen other programs which didn't like it at all (gzip or bzip2 for example). CPU intensive programs optimized for i686 which use lots of CMOV for example, need about 400 cycles to do a simple CMOV ! this can slow down things to an order of more than 100 when placed in an inner loop. So to resume, everything can be done through emulation, but that's probably not what we want as a standard for performance reasons. When I have time, I may port it to 2.6, but that's not no my priority list. Cheers, Willy ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 7:17 ` Willy Tarreau @ 2003-07-31 15:07 ` Jamie Lokier 2003-07-31 15:23 ` Willy Tarreau 2003-07-31 15:50 ` Richard B. Johnson 0 siblings, 2 replies; 35+ messages in thread From: Jamie Lokier @ 2003-07-31 15:07 UTC (permalink / raw) To: Willy Tarreau; +Cc: lkml Willy Tarreau wrote: > The other problem lies with the lock : > When a 486 executes "LOCK ; CMPXCHG", it locks the bus during the whole cmpxchg > instruction. If a 386 executes the same code, it will get an exception which > will be caught by the emulator. I don't see how we can do such an atomic > operation while holding a lock. At best, we would think about a global memory > based shared lock during the operation (eg: int bus_lock;), but it's not > implemented at the moment, and will only be compatible with processors sharing > the same code. Add-on processors, such as co-processors, transputer cards, or > DSPs, will know nothing about such a lock emulation. And it would result in > even poorer performance of course ! Of course this is not a problem when "lock;cmpxchg" is used only for thread synchronisation on uniprocessor 386s... The lock prefix is irrelevant then. Perhaps the emulation should refuse to pretend to work on an SMP 386 :) -- Jamie ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 15:07 ` Jamie Lokier @ 2003-07-31 15:23 ` Willy Tarreau 2003-07-31 15:50 ` Richard B. Johnson 1 sibling, 0 replies; 35+ messages in thread From: Willy Tarreau @ 2003-07-31 15:23 UTC (permalink / raw) To: Jamie Lokier; +Cc: Willy Tarreau, lkml On Thu, Jul 31, 2003 at 04:07:58PM +0100, Jamie Lokier wrote: > Of course this is not a problem when "lock;cmpxchg" is used only for thread > synchronisation on uniprocessor 386s... The lock prefix is irrelevant then. This is exactly what it written in configure.help ;-) > Perhaps the emulation should refuse to pretend to work on an SMP 386 :) I've seen such a config once. In fact, it was a board with two i376 (the 386 equivalent which does protected mode only, no M86 nor real mode). But I never knew if they were connected to the same bus or totally independant. Cheers, Willy ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 15:07 ` Jamie Lokier 2003-07-31 15:23 ` Willy Tarreau @ 2003-07-31 15:50 ` Richard B. Johnson 2003-07-31 16:24 ` Jan-Benedict Glaw 1 sibling, 1 reply; 35+ messages in thread From: Richard B. Johnson @ 2003-07-31 15:50 UTC (permalink / raw) To: Jamie Lokier; +Cc: Willy Tarreau, lkml On Thu, 31 Jul 2003, Jamie Lokier wrote: > Willy Tarreau wrote: > > The other problem lies with the lock : > > When a 486 executes "LOCK ; CMPXCHG", it locks the bus during the whole cmpxchg > > instruction. If a 386 executes the same code, it will get an exception which > > will be caught by the emulator. I don't see how we can do such an atomic > > operation while holding a lock. At best, we would think about a global memory > > based shared lock during the operation (eg: int bus_lock;), but it's not > > implemented at the moment, and will only be compatible with processors sharing > > the same code. Add-on processors, such as co-processors, transputer cards, or > > DSPs, will know nothing about such a lock emulation. And it would result in > > even poorer performance of course ! > > Of course this is not a problem when "lock;cmpxchg" is used only for thread > synchronisation on uniprocessor 386s... The lock prefix is irrelevant then. > > Perhaps the emulation should refuse to pretend to work on an SMP 386 :) > > -- Jamie > - You can use the lock instruction ahead of any 386 instruction without creating an exception. When relevent, it locks the whole bus. When not, it's just a no-op. The trap on the lock instruction came with the '486. With the '486, if the instruction doesn't modify memory, then the lock prefix is invalid and will generate an invalid-opcode exception. It is not correct to use a lock instruction in front of every op-code of course, and it might not have been tested for all corner cases, but generally it's harmless on a '386. The bad op-code for the i386 is cmpxchg. This is what triggers the trap. This can be emulated, although the emulation is not SMP compatible. You worry about this when somebody makes a dual '386 machine ;^). Also, the best performing emulation for any op-codes should be done within the kernel. That way, the invalid-opcode trap works just like the math emulator. You don't need the overhead of calling a user-mode handler. If this is emulation is implimented, then one should also emulate BSWAP and XADD. This makes '486 code compatible with '386 machines. Cheers, Dick Johnson Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 15:50 ` Richard B. Johnson @ 2003-07-31 16:24 ` Jan-Benedict Glaw 0 siblings, 0 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 16:24 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1427 bytes --] On Thu, 2003-07-31 11:50:27 -0400, Richard B. Johnson <root@chaos.analogic.com> wrote in message <Pine.LNX.4.53.0307311126530.770@chaos>: > On Thu, 31 Jul 2003, Jamie Lokier wrote: > > Willy Tarreau wrote: > The bad op-code for the i386 is cmpxchg. This is what triggers > the trap. This can be emulated, although the emulation is > not SMP compatible. You worry about this when somebody makes > a dual '386 machine ;^). Also, the best performing emulation > for any op-codes should be done within the kernel. That way, > the invalid-opcode trap works just like the math emulator. You > don't need the overhead of calling a user-mode handler. If > this is emulation is implimented, then one should also emulate > BSWAP and XADD. This makes '486 code compatible with '386 > machines. Thanks for this fine explanation! Maybe I'd take the 2.4.x emulator kernel patch and bring it in line with 2.6.x? However, that doesn't release gcc's developers from providing a solution to the initial problem (i386 and i486 compiled libs/programs incompatible) from the task to work on libstdc++ :-> MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:01 ` Alan Cox 2003-07-30 20:33 ` Jan-Benedict Glaw @ 2003-08-06 11:08 ` Pavel Machek 2003-08-06 14:33 ` Maciej W. Rozycki 1 sibling, 1 reply; 35+ messages in thread From: Pavel Machek @ 2003-08-06 11:08 UTC (permalink / raw) To: Alan Cox; +Cc: Adrian Bunk, lkml Hi! > > Note that this can also allow Step-A 486's to correctly run multi-thread > > applications since cmpxchg has a wrong opcode on this early CPU. > > > > Don't use this to enable multi-threading on an SMP machine, the lock > > atomicity can't be guaranted! > > That is of course the other problem with this approach - you can't > really get the intended results without some extremely heavyweight code > (using an IPI to halt all CPU's, doing the access and then resuming > them) Hopefully there are not too many SMP-486 machines out there ;-). Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-08-06 11:08 ` Pavel Machek @ 2003-08-06 14:33 ` Maciej W. Rozycki 0 siblings, 0 replies; 35+ messages in thread From: Maciej W. Rozycki @ 2003-08-06 14:33 UTC (permalink / raw) To: Pavel Machek; +Cc: Alan Cox, Adrian Bunk, lkml On Wed, 6 Aug 2003, Pavel Machek wrote: > > > Note that this can also allow Step-A 486's to correctly run multi-thread > > > applications since cmpxchg has a wrong opcode on this early CPU. > > > > > > Don't use this to enable multi-threading on an SMP machine, the lock > > > atomicity can't be guaranted! > > > > That is of course the other problem with this approach - you can't > > really get the intended results without some extremely heavyweight code > > (using an IPI to halt all CPU's, doing the access and then resuming > > them) > > Hopefully there are not too many SMP-486 machines out there ;-). Step-A i486 processors are supposedly very rare and they were the earliest ones (predating the DX suffix), so they were probably never used for SMP systems. And I think the i82489DX APIC was introduced a bit later anyway -- we don't support non-APIC SMP implementations. BTW, the step-A i486 reused opcodes of the famous i386's ibts and xbts instructions. Once the chips were out, Intel discovered there is actually some software out there expecting ibts/xbts semantics with these opcodes, so the encoding of cmpxchg was quickly changed. ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:45 ` Adrian Bunk 2003-07-30 20:01 ` Alan Cox @ 2003-07-30 20:28 ` Jan-Benedict Glaw 2003-07-30 21:50 ` Petr Vandrovec 1 sibling, 1 reply; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 20:28 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1550 bytes --] On Wed, 2003-07-30 20:45:29 +0200, Adrian Bunk <bunk@fs.tum.de> wrote in message <20030730184529.GE21734@fs.tum.de>: > On Wed, Jul 30, 2003 at 11:30:33AM -0700, Mike Fedyk wrote: > > On Wed, Jul 30, 2003 at 08:10:06PM +0200, Adrian Bunk wrote: > > > On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: > > > > Please apply. Worst to say, even Debian seems to start using i486+ > > > > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > > > > "lock" insn available)... > > > > > > Shouldn't the 486 emulation in the latest 386 kernel images in Debian > > > unstable take care of this? > > > > What emulation? > > 486 emulation > CONFIG_CPU_EMU486 > When used on a 386, Linux can emulate 3 instructions from the 486 set. > This allows user space programs compiled for 486 to run on a 386 > without crashing with a SIGILL. As any emulation, performance will be > very low, but since these instruction are not often used, this might > not hurt. The emulated instructions are: > - bswap (does the same as htonl()) > - cmpxchg (used in multi-threading, mutex locking) > - xadd (rarely used) libstdc++ (and it's main user, apt-get) break at a LOCK insn. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:28 ` Jan-Benedict Glaw @ 2003-07-30 21:50 ` Petr Vandrovec 2003-07-30 23:10 ` Alan Cox 2003-07-31 6:29 ` Jan-Benedict Glaw 0 siblings, 2 replies; 35+ messages in thread From: Petr Vandrovec @ 2003-07-30 21:50 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 10:28:22PM +0200, Jan-Benedict Glaw wrote: > On Wed, 2003-07-30 20:45:29 +0200, Adrian Bunk <bunk@fs.tum.de> > > When used on a 386, Linux can emulate 3 instructions from the 486 set. > > This allows user space programs compiled for 486 to run on a 386 > > without crashing with a SIGILL. As any emulation, performance will be > > very low, but since these instruction are not often used, this might > > not hurt. The emulated instructions are: > > - bswap (does the same as htonl()) > > - cmpxchg (used in multi-threading, mutex locking) > > - xadd (rarely used) > > libstdc++ (and it's main user, apt-get) break at a LOCK insn. There is no such instruction. Skip LOCK prefix and decode again, you'll get either cmpxchg or xadd (or cmpxchg8b, but then it does not work on i486 too). And yes, it speeds some workloads a lot. Best to look at code, with these instructions you can do couple of operations without doing IPC to synchronize with other threads. And as far as I know, userspace solution does not qualify: major user is synchronization between threads, so with userspace solution you will have to do very hard job to get it right (first implement your own synchronization, if possible without busy waiting... and then implement cmpxchg on the top of it), while kernel solution can do that simple & correct for UP case. Best regards, Petr Vandrovec vandrove@vc.cvut.cz ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 21:50 ` Petr Vandrovec @ 2003-07-30 23:10 ` Alan Cox 2003-07-31 15:10 ` Jamie Lokier 2003-07-31 6:29 ` Jan-Benedict Glaw 1 sibling, 1 reply; 35+ messages in thread From: Alan Cox @ 2003-07-30 23:10 UTC (permalink / raw) To: Petr Vandrovec; +Cc: lkml On Mer, 2003-07-30 at 22:50, Petr Vandrovec wrote: > There is no such instruction. Skip LOCK prefix and decode again, > you'll get either cmpxchg or xadd (or cmpxchg8b, but then it does > not work on i486 too). And if the byte you are looking at was patched by another thread you've blown it. Your emulation can only be so good 8) People do stuff like patching instructions under software decode as a robustness check - its normally pretty amusing ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 23:10 ` Alan Cox @ 2003-07-31 15:10 ` Jamie Lokier 2003-07-31 16:01 ` Alan Cox 0 siblings, 1 reply; 35+ messages in thread From: Jamie Lokier @ 2003-07-31 15:10 UTC (permalink / raw) To: Alan Cox; +Cc: Petr Vandrovec, lkml Alan Cox wrote: > On Mer, 2003-07-30 at 22:50, Petr Vandrovec wrote: > > There is no such instruction. Skip LOCK prefix and decode again, > > you'll get either cmpxchg or xadd (or cmpxchg8b, but then it does > > not work on i486 too). > > And if the byte you are looking at was patched by another thread you've > blown it. Your emulation can only be so good 8) People do stuff like > patching instructions under software decode as a robustness check - its > normally pretty amusing On a uniprocessor 386, this is not a problem. Just disable preemption in the kernel decoder. Of course if you do it in userspace using SIGILL, then it is broken :) -- Jamie ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 15:10 ` Jamie Lokier @ 2003-07-31 16:01 ` Alan Cox 2003-07-31 18:37 ` Jamie Lokier 0 siblings, 1 reply; 35+ messages in thread From: Alan Cox @ 2003-07-31 16:01 UTC (permalink / raw) To: Jamie Lokier; +Cc: Petr Vandrovec, lkml On Iau, 2003-07-31 at 16:10, Jamie Lokier wrote: > > And if the byte you are looking at was patched by another thread you've > > blown it. Your emulation can only be so good 8) People do stuff like > > patching instructions under software decode as a robustness check - its > > normally pretty amusing > > On a uniprocessor 386, this is not a problem. Just disable preemption > in the kernel decoder. Wrong again. Thats a common myth but you see I can put the instruction on a page so that its executed from a page I just did a read() into in another process. If I'm really bored I'll use O_DIRECT but thats mostly for makign life really bad for non cache coherent setups 8) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 16:01 ` Alan Cox @ 2003-07-31 18:37 ` Jamie Lokier 2003-07-31 19:10 ` Alan Cox 0 siblings, 1 reply; 35+ messages in thread From: Jamie Lokier @ 2003-07-31 18:37 UTC (permalink / raw) To: Alan Cox; +Cc: Petr Vandrovec, lkml Alan Cox wrote: > > > And if the byte you are looking at was patched by another thread you've > > > blown it. Your emulation can only be so good 8) People do stuff like > > > patching instructions under software decode as a robustness check - its > > > normally pretty amusing > > > > On a uniprocessor 386, this is not a problem. Just disable preemption > > in the kernel decoder. > > Wrong again. Thats a common myth but you see I can put the instruction on a page > so that its executed from a page I just did a read() into in another process. If > I'm really bored I'll use O_DIRECT but thats mostly for makign life really bad > for non cache coherent setups 8) I wouldn't be surprised if even real CPUs mis-decode when there's a concurrent DMA into the area they are reading instructions from! :) -- Jamie ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 18:37 ` Jamie Lokier @ 2003-07-31 19:10 ` Alan Cox 0 siblings, 0 replies; 35+ messages in thread From: Alan Cox @ 2003-07-31 19:10 UTC (permalink / raw) To: Jamie Lokier; +Cc: Petr Vandrovec, lkml On Iau, 2003-07-31 at 19:37, Jamie Lokier wrote: > I wouldn't be surprised if even real CPUs mis-decode when there's a > concurrent DMA into the area they are reading instructions from! :) I believe there is a PIII errata about putting an instruction across a memory type boundary and executingit in a loop ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 21:50 ` Petr Vandrovec 2003-07-30 23:10 ` Alan Cox @ 2003-07-31 6:29 ` Jan-Benedict Glaw 1 sibling, 0 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 6:29 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1268 bytes --] On Wed, 2003-07-30 23:50:32 +0200, Petr Vandrovec <vandrove@vc.cvut.cz> wrote in message <20030730215032.GA18892@vana.vc.cvut.cz>: > On Wed, Jul 30, 2003 at 10:28:22PM +0200, Jan-Benedict Glaw wrote: > > On Wed, 2003-07-30 20:45:29 +0200, Adrian Bunk <bunk@fs.tum.de> > And yes, it speeds some workloads a lot. Best to look at code, > with these instructions you can do couple of operations without > doing IPC to synchronize with other threads. Which ones? I am always told "it's faster, then", but nobody really proofed that. Take some multithreadded apps. How often do they *really* lock/unlock mutexes, and in which ratio does that compare to their "normal" computing needs? If an application's main job is locking/unlocking mutexes, then the author should possibly think about that. If it's main task is to do the computational stuff, then I've got no (real) problem with this extra Linux^Wtax, esp. on those faster boxes... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:10 ` Adrian Bunk 2003-07-30 18:30 ` Mike Fedyk @ 2003-07-30 20:27 ` Jan-Benedict Glaw 1 sibling, 0 replies; 35+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 20:27 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1224 bytes --] On Wed, 2003-07-30 20:10:06 +0200, Adrian Bunk <bunk@fs.tum.de> wrote in message <20030730181006.GB21734@fs.tum.de>: > On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: > >... > > Please apply. Worst to say, even Debian seems to start using i486+ > > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > > "lock" insn available)... > > Shouldn't the 486 emulation in the latest 386 kernel images in Debian > unstable take care of this? Specifically patched kernel? Sounds lame to me... Generic solution would be to have a generic implementation, IMHO. Up to now, I've nowhere found some hard facts that the new opcodes do measureable speed up things. Sure, saving some hundreds/thousands/... CPU cycles is nice - but not, if that's only 0.1% of the whole number of CPU cycles burned in a run. That doesn't, IMHO, really legitimate do unsupport the i386. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2003-08-06 16:47 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-08-06 16:45 TSCs are a no-no on i386 James Bottomley -- strict thread matches above, loose matches on Subject: below -- 2003-08-06 16:41 James Bottomley 2003-07-30 13:56 Jan-Benedict Glaw 2003-07-30 14:18 ` Maciej W. Rozycki 2003-07-30 14:44 ` Jan-Benedict Glaw 2003-07-30 16:58 ` Matthew Garrett 2003-07-30 17:19 ` Alan Cox 2003-07-30 18:10 ` Adrian Bunk 2003-07-30 18:30 ` Mike Fedyk 2003-07-30 18:45 ` Adrian Bunk 2003-07-30 20:01 ` Alan Cox 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-07-30 22:19 ` J.A. Magallon 2003-07-31 6:11 ` Jan-Benedict Glaw 2003-07-30 23:05 ` Alan Cox 2003-07-31 11:11 ` Richard B. Johnson 2003-07-31 11:41 ` Jan-Benedict Glaw 2003-07-31 0:22 ` Adrian Bunk 2003-07-31 6:22 ` Jan-Benedict Glaw 2003-07-31 7:17 ` Willy Tarreau 2003-07-31 15:07 ` Jamie Lokier 2003-07-31 15:23 ` Willy Tarreau 2003-07-31 15:50 ` Richard B. Johnson 2003-07-31 16:24 ` Jan-Benedict Glaw 2003-08-06 11:08 ` Pavel Machek 2003-08-06 14:33 ` Maciej W. Rozycki 2003-07-30 20:28 ` Jan-Benedict Glaw 2003-07-30 21:50 ` Petr Vandrovec 2003-07-30 23:10 ` Alan Cox 2003-07-31 15:10 ` Jamie Lokier 2003-07-31 16:01 ` Alan Cox 2003-07-31 18:37 ` Jamie Lokier 2003-07-31 19:10 ` Alan Cox 2003-07-31 6:29 ` Jan-Benedict Glaw 2003-07-30 20:27 ` Jan-Benedict Glaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).