Recently, I found such piece of code in kernel 2.6.28 compiled for 386
processor:
# grep M386 .config
CONFIG_M386=y
# objdump -d vmlinux | grep -A11 '<_spin_lock>:'
c0321827 <_spin_lock>:
c0321827: 89 e2 mov %esp,%edx
c0321829: 81 e2 00 f0 ff ff and $0xfffff000,%edx
c032182f: ff 42 14 incl 0x14(%edx)
c0321832: ba 00 01 00 00 mov $0x100,%edx
c0321837: f0 66 0f c1 10 lock xadd %dx,(%eax)
c032183c: 38 f2 cmp %dh,%dl
c032183e: 74 06 je c0321846 <_spin_lock+0x1f>
c0321840: f3 90 pause
c0321842: 8a 10 mov (%eax),%dl
c0321844: eb f6 jmp c032183c <_spin_lock+0x15>
c0321846: c3 ret
But there is no xadd instruction on 386 processors. It is available on
486+ only. I have no chance to run this kernel on real 386 box, so I can't
check it in practice, but I think it will not run.
It is not compiler problem because it is explicitly written in assembly
in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
no alternative code depending on CONFIG_M386.
Regards.
[ CCs added ]
On Thu, 8 Jan 2009, Adam Osuchowski wrote:
> Recently, I found such piece of code in kernel 2.6.28 compiled for 386
> processor:
>
> # grep M386 .config
> CONFIG_M386=y
> # objdump -d vmlinux | grep -A11 '<_spin_lock>:'
> c0321827 <_spin_lock>:
> c0321827: 89 e2 mov %esp,%edx
> c0321829: 81 e2 00 f0 ff ff and $0xfffff000,%edx
> c032182f: ff 42 14 incl 0x14(%edx)
> c0321832: ba 00 01 00 00 mov $0x100,%edx
> c0321837: f0 66 0f c1 10 lock xadd %dx,(%eax)
> c032183c: 38 f2 cmp %dh,%dl
> c032183e: 74 06 je c0321846 <_spin_lock+0x1f>
> c0321840: f3 90 pause
> c0321842: 8a 10 mov (%eax),%dl
> c0321844: eb f6 jmp c032183c <_spin_lock+0x15>
> c0321846: c3 ret
>
> But there is no xadd instruction on 386 processors. It is available on
> 486+ only. I have no chance to run this kernel on real 386 box, so I can't
> check it in practice, but I think it will not run.
>
> It is not compiler problem because it is explicitly written in assembly
> in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
> no alternative code depending on CONFIG_M386.
Hmm, this really looks like a bug to me. How about something like this
(untested).
From: Jiri Kosina <[email protected]>
Subject: x86: make spinlocks available on machines without xadd insn
Current kernel wouldn't compile on ancient x86 machines that don't support
xadd instruction, as ticket spinlocks implementation unconditionally uses
it.
On machines without CONFIG_X86_XADD, use old-style byte spinlock
implementation instead.
Reported-by: Adam Osuchowski <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index d17c919..b3bc71b 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -236,6 +236,40 @@ static inline void __byte_spin_unlock(raw_spinlock_t *lock)
bl->lock = 0;
}
#else /* !CONFIG_PARAVIRT */
+
+/* old x86 machines do not have xadd insns, use old-style locks for them */
+#ifndef CONFIG_X86_XADD
+static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
+{
+ return __byte_spin_is_locked(lock);
+}
+
+static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
+{
+ return __byte_spin_is_contended(lock);
+}
+
+static __always_inline void __raw_spin_lock(raw_spinlock_t *lock)
+{
+ __byte_spin_lock(lock);
+}
+
+static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock)
+{
+ return __byte_spin_trylock(lock);
+}
+
+static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
+{
+ __byte_spin_unlock(lock);
+}
+
+static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
+ unsigned long flags)
+{
+ __raw_spin_lock(lock);
+}
+#else /* CONFIG_X86_XADD */
static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
{
return __ticket_spin_is_locked(lock);
@@ -267,6 +301,7 @@ static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
__raw_spin_lock(lock);
}
+#endif /* CONFIG_X86_XADD */
#endif /* CONFIG_PARAVIRT */
static inline void __raw_spin_unlock_wait(raw_spinlock_t *lock)
[Jiri Kosina - Thu, Jan 08, 2009 at 02:05:48PM +0100]
|
| [ CCs added ]
|
| On Thu, 8 Jan 2009, Adam Osuchowski wrote:
|
| > Recently, I found such piece of code in kernel 2.6.28 compiled for 386
| > processor:
| >
| > # grep M386 .config
| > CONFIG_M386=y
| > # objdump -d vmlinux | grep -A11 '<_spin_lock>:'
| > c0321827 <_spin_lock>:
| > c0321827: 89 e2 mov %esp,%edx
| > c0321829: 81 e2 00 f0 ff ff and $0xfffff000,%edx
| > c032182f: ff 42 14 incl 0x14(%edx)
| > c0321832: ba 00 01 00 00 mov $0x100,%edx
| > c0321837: f0 66 0f c1 10 lock xadd %dx,(%eax)
| > c032183c: 38 f2 cmp %dh,%dl
| > c032183e: 74 06 je c0321846 <_spin_lock+0x1f>
| > c0321840: f3 90 pause
| > c0321842: 8a 10 mov (%eax),%dl
| > c0321844: eb f6 jmp c032183c <_spin_lock+0x15>
| > c0321846: c3 ret
| >
| > But there is no xadd instruction on 386 processors. It is available on
| > 486+ only. I have no chance to run this kernel on real 386 box, so I can't
| > check it in practice, but I think it will not run.
| >
| > It is not compiler problem because it is explicitly written in assembly
| > in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
| > no alternative code depending on CONFIG_M386.
|
| Hmm, this really looks like a bug to me. How about something like this
| (untested).
|
|
| From: Jiri Kosina <[email protected]>
| Subject: x86: make spinlocks available on machines without xadd insn
|
| Current kernel wouldn't compile on ancient x86 machines that don't support
| xadd instruction, as ticket spinlocks implementation unconditionally uses
| it.
|
| On machines without CONFIG_X86_XADD, use old-style byte spinlock
| implementation instead.
|
| Reported-by: Adam Osuchowski <[email protected]>
| Signed-off-by: Jiri Kosina <[email protected]>
|
| diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
| index d17c919..b3bc71b 100644
| --- a/arch/x86/include/asm/spinlock.h
| +++ b/arch/x86/include/asm/spinlock.h
| @@ -236,6 +236,40 @@ static inline void __byte_spin_unlock(raw_spinlock_t *lock)
| bl->lock = 0;
| }
| #else /* !CONFIG_PARAVIRT */
| +
| +/* old x86 machines do not have xadd insns, use old-style locks for them */
| +#ifndef CONFIG_X86_XADD
| +static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
| +{
| + return __byte_spin_is_locked(lock);
| +}
| +
| +static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
| +{
| + return __byte_spin_is_contended(lock);
| +}
| +
| +static __always_inline void __raw_spin_lock(raw_spinlock_t *lock)
| +{
| + __byte_spin_lock(lock);
| +}
| +
| +static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock)
| +{
| + return __byte_spin_trylock(lock);
| +}
| +
| +static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
| +{
| + __byte_spin_unlock(lock);
| +}
| +
| +static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
| + unsigned long flags)
| +{
| + __raw_spin_lock(lock);
| +}
| +#else /* CONFIG_X86_XADD */
| static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
| {
| return __ticket_spin_is_locked(lock);
| @@ -267,6 +301,7 @@ static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
| __raw_spin_lock(lock);
| }
|
| +#endif /* CONFIG_X86_XADD */
| #endif /* CONFIG_PARAVIRT */
|
| static inline void __raw_spin_unlock_wait(raw_spinlock_t *lock)
|
Jiri I could be wrong but it seems __byte_spin_lock is implemented
under CONFIG_PARAVIRT and now referred under #else /* !CONFIG_PARAVIRT */
At least I didn'y found additional implementaion in tree.
Did I miss anything?
- Cyrill -
On Thu, 8 Jan 2009, Cyrill Gorcunov wrote:
> Jiri I could be wrong but it seems __byte_spin_lock is implemented
> under CONFIG_PARAVIRT and now referred under #else /* !CONFIG_PARAVIRT */
> At least I didn'y found additional implementaion in tree.
> Did I miss anything?
You're right, my bad. There is going to be some ifdef ugliness introduced
by this unfortunately, but on the other hand it's pretty straightforward.
From: Jiri Kosina <[email protected]>
Subject: x86: make spinlocks available on machines without xadd insn
Current kernel wouldn't compile on ancient x86 machines that don't support
xadd instruction, as ticket spinlocks implementation unconditionally uses
it.
On machines without CONFIG_X86_XADD, use old-style byte spinlock
implementation instead.
Reported-by: Adam Osuchowski <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
---
arch/x86/include/asm/spinlock.h | 28 ++++++++++++++++++++++++----
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index d17c919..1331333 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -172,10 +172,10 @@ static inline int __ticket_spin_is_contended(raw_spinlock_t *lock)
return (((tmp >> TICKET_SHIFT) - tmp) & ((1 << TICKET_SHIFT) - 1)) > 1;
}
-#ifdef CONFIG_PARAVIRT
+#if defined(CONFIG_PARAVIRT) || !defined(CONFIG_X86_XADD)
/*
* Define virtualization-friendly old-style lock byte lock, for use in
- * pv_lock_ops if desired.
+ * pv_lock_ops or for machines not supporting xadd instruction.
*
* This differs from the pre-2.6.24 spinlock by always using xchgb
* rather than decb to take the lock; this allows it to use a
@@ -235,30 +235,50 @@ static inline void __byte_spin_unlock(raw_spinlock_t *lock)
smp_wmb();
bl->lock = 0;
}
-#else /* !CONFIG_PARAVIRT */
+#else
static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
{
+#ifdef CONFIG_X86_XADD
return __ticket_spin_is_locked(lock);
+#else
+ return __byte_spin_is_locked(lock);
+#endif
}
static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
{
+#ifdef CONFIG_X86_XADD
return __ticket_spin_is_contended(lock);
+#else
+ return __byte_spin_is_contended(lock);
+#endif
}
static __always_inline void __raw_spin_lock(raw_spinlock_t *lock)
{
+#ifdef CONFIG_X86_XADD
__ticket_spin_lock(lock);
+#else
+ __byte_spin_lock(lock);
+#endif
}
static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock)
{
+#ifdef CONFIG_X86_XADD
return __ticket_spin_trylock(lock);
+#else
+ return __byte_spin_trylock(lock);
+#endif
}
static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
{
+#ifdef CONFIG_X86_XADD
__ticket_spin_unlock(lock);
+#else
+ __byte_spin_unlock(lock);
+#endif
}
static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
@@ -267,7 +287,7 @@ static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
__raw_spin_lock(lock);
}
-#endif /* CONFIG_PARAVIRT */
+#endif
static inline void __raw_spin_unlock_wait(raw_spinlock_t *lock)
{
On Thu, 2009-01-08 at 14:05 +0100, Jiri Kosina wrote:
> [ CCs added ]
>
> On Thu, 8 Jan 2009, Adam Osuchowski wrote:
>
> > Recently, I found such piece of code in kernel 2.6.28 compiled for 386
> > processor:
> >
> > # grep M386 .config
> > CONFIG_M386=y
> > # objdump -d vmlinux | grep -A11 '<_spin_lock>:'
> > c0321827 <_spin_lock>:
> > c0321827: 89 e2 mov %esp,%edx
> > c0321829: 81 e2 00 f0 ff ff and $0xfffff000,%edx
> > c032182f: ff 42 14 incl 0x14(%edx)
> > c0321832: ba 00 01 00 00 mov $0x100,%edx
> > c0321837: f0 66 0f c1 10 lock xadd %dx,(%eax)
> > c032183c: 38 f2 cmp %dh,%dl
> > c032183e: 74 06 je c0321846 <_spin_lock+0x1f>
> > c0321840: f3 90 pause
> > c0321842: 8a 10 mov (%eax),%dl
> > c0321844: eb f6 jmp c032183c <_spin_lock+0x15>
> > c0321846: c3 ret
> >
> > But there is no xadd instruction on 386 processors. It is available on
> > 486+ only. I have no chance to run this kernel on real 386 box, so I can't
> > check it in practice, but I think it will not run.
> >
> > It is not compiler problem because it is explicitly written in assembly
> > in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
> > no alternative code depending on CONFIG_M386.
>
> Hmm, this really looks like a bug to me. How about something like this
> (untested).
>
>
> From: Jiri Kosina <[email protected]>
> Subject: x86: make spinlocks available on machines without xadd insn
>
> Current kernel wouldn't compile on ancient x86 machines that don't support
> xadd instruction, as ticket spinlocks implementation unconditionally uses
> it.
>
> On machines without CONFIG_X86_XADD, use old-style byte spinlock
> implementation instead.
afaik we don't support i386-smp and up spinlocks are trivial
preempt_disable() calls.
On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> > Subject: x86: make spinlocks available on machines without xadd insn
> > Current kernel wouldn't compile on ancient x86 machines that don't support
> > xadd instruction, as ticket spinlocks implementation unconditionally uses
> > it.
> > On machines without CONFIG_X86_XADD, use old-style byte spinlock
> > implementation instead.
> afaik we don't support i386-smp and up spinlocks are trivial
> preempt_disable() calls.
Hmm. Where in Kconfig is SMP for M386 not allowed?
--
Jiri Kosina
SUSE Labs
On Thu, 2009-01-08 at 15:21 +0100, Jiri Kosina wrote:
> On Thu, 8 Jan 2009, Peter Zijlstra wrote:
>
> > > Subject: x86: make spinlocks available on machines without xadd insn
> > > Current kernel wouldn't compile on ancient x86 machines that don't support
> > > xadd instruction, as ticket spinlocks implementation unconditionally uses
> > > it.
> > > On machines without CONFIG_X86_XADD, use old-style byte spinlock
> > > implementation instead.
> > afaik we don't support i386-smp and up spinlocks are trivial
> > preempt_disable() calls.
>
> Hmm. Where in Kconfig is SMP for M386 not allowed?
Dunno, kconfig is too much of a jungle for a simple person like me ;-)
But afaik i386 (and possibly i486) don't support nearly enough for a
modern SMP system.
Alan used to have i486-smp I think, one of the very few ever made.
> > Hmm. Where in Kconfig is SMP for M386 not allowed?
>
> Dunno, kconfig is too much of a jungle for a simple person like me ;-)
>
> But afaik i386 (and possibly i486) don't support nearly enough for a
> modern SMP system.
>
> Alan used to have i486-smp I think, one of the very few ever made.
The first systems that supported the Intel MP standard are 486 based with
external APIC. The prior systems used various proprietary MP interfaces
from the simple stuff in the Compaq (which Linux doesn't support as
Compaq refused to allow Thomas Radke to contribute it) to the fairly
extreme end of things with the Sequent boxes.
In addition our FPU emulation and some of our handling for x86 processors
where we have to do the WP bit in software is also not SMP safe.
So our minimal spec for SMP is probably 486DX + external Intel APIC.
In practice I doubt there is a single Intel APIC type 486 SMP box on the
planet running Linux (or quite possibly running at all)
Alan
* Alan Cox <[email protected]> wrote:
> > > Hmm. Where in Kconfig is SMP for M386 not allowed?
> >
> > Dunno, kconfig is too much of a jungle for a simple person like me ;-)
> >
> > But afaik i386 (and possibly i486) don't support nearly enough for a
> > modern SMP system.
> >
> > Alan used to have i486-smp I think, one of the very few ever made.
>
> The first systems that supported the Intel MP standard are 486 based
> with external APIC. The prior systems used various proprietary MP
> interfaces from the simple stuff in the Compaq (which Linux doesn't
> support as Compaq refused to allow Thomas Radke to contribute it) to the
> fairly extreme end of things with the Sequent boxes.
>
> In addition our FPU emulation and some of our handling for x86
> processors where we have to do the WP bit in software is also not SMP
> safe.
>
> So our minimal spec for SMP is probably 486DX + external Intel APIC.
>
> In practice I doubt there is a single Intel APIC type 486 SMP box on the
> planet running Linux (or quite possibly running at all)
yeah, that's very likely true. I think we could eliminate some of the SMP
complications by requiring cmpxchg presence for CONFIG_SMP, agreed?
Ingo
Jiri Kosina <[email protected]> writes:
>
> From: Jiri Kosina <[email protected]>
> Subject: x86: make spinlocks available on machines without xadd insn
>
> Current kernel wouldn't compile on ancient x86 machines that don't support
> xadd instruction, as ticket spinlocks implementation unconditionally uses
> it.
>
> On machines without CONFIG_X86_XADD, use old-style byte spinlock
> implementation instead.
The assumption was always the 386s don't run SMP.
So I think it would be better if you just made these xadds
part of the UP patch implementation and patch them out on
UP systems similar to how it's done for LOCK prefixes.
That would help non 386 UP systems too.
-Andi
--
[email protected]
On Thu, Jan 08, 2009 at 03:27:13PM +0100, Peter Zijlstra wrote:
> On Thu, 2009-01-08 at 15:21 +0100, Jiri Kosina wrote:
> > On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> >
> > > > Subject: x86: make spinlocks available on machines without xadd insn
> > > > Current kernel wouldn't compile on ancient x86 machines that don't support
> > > > xadd instruction, as ticket spinlocks implementation unconditionally uses
> > > > it.
> > > > On machines without CONFIG_X86_XADD, use old-style byte spinlock
> > > > implementation instead.
> > > afaik we don't support i386-smp and up spinlocks are trivial
> > > preempt_disable() calls.
> >
> > Hmm. Where in Kconfig is SMP for M386 not allowed?
>
> Dunno, kconfig is too much of a jungle for a simple person like me ;-)
Kconfig for x86 does nothing to prevent us from selecting SMP
when we have selected the 386 processor variant.
But then you need to enable the CONFIG_EXPERT(*) option to
select CPU type - which imply you know what you are doing.
(*) Named CONFIG_EMBEDDED for some reason.
Sam
On Thu, 8 Jan 2009, Ingo Molnar wrote:
> > So our minimal spec for SMP is probably 486DX + external Intel APIC.
> >
> > In practice I doubt there is a single Intel APIC type 486 SMP box on the
> > planet running Linux (or quite possibly running at all)
>
> yeah, that's very likely true. I think we could eliminate some of the SMP
> complications by requiring cmpxchg presence for CONFIG_SMP, agreed?
I failed to track down a single 486 SMP system that would adhere to the
MP spec. There were and possibly still are APIC-based 486 SMP systems out
there, but most likely they are not Intel MPS-compliant, by not providing
the MP header at the very least. Thus Linux would have to be ported and I
gather the interest in doing so is epsilon.
Myself, I could not resist trying an APIC-based 486 SMP box and possibly
fixing issues if I found one and it was MPS-compliant, but nothing beyond
that I would say. Life's too short.
Maciej
On Tue, 2009-01-13 01:06:55 +0000, Maciej W. Rozycki <[email protected]> wrote:
>
> Myself, I could not resist trying an APIC-based 486 SMP box and possibly
> fixing issues if I found one and it was MPS-compliant, but nothing beyond
> that I would say. Life's too short.
While it is not SMP, I still have one or two working i386 (and
a compatible AMD) system around.
Back in the days where I ran them the last time, there were two
issues:
* Debian's baseline libc is compiled to use LOCK and some other
newish instructions that are not available on a real i386 CPU.
* There was a patch flying around to introduce a kernel-based
emulator for those instructions. However, this was (at that time)
neither included in Debian's kernel, nor in the upstream sources.
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: http://www.eyrie.org/~eagle/faqs/questions.html
the second :
On Thu, 15 Jan 2009, Jan-Benedict Glaw wrote:
> * Debian's baseline libc is compiled to use LOCK and some other
> newish instructions that are not available on a real i386 CPU.
LOCK dates back to the 8086 -- it has to work with the i386. What is not
supported are the following i486 additions: CMPXCHG (amusingly enough
early i486 steppings used a different opcode for this one; no idea if it
is still possible to find such a CPU), XADD and BSWAP, the latter being
fairly unimportant.
> * There was a patch flying around to introduce a kernel-based
> emulator for those instructions. However, this was (at that time)
> neither included in Debian's kernel, nor in the upstream sources.
UP emulation of CMPXCHG and XADD for userland should be rather trivial,
so why not include it like with LL/SC for MIPS?
Maciej
> UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> so why not include it like with LL/SC for MIPS?
Why not just ship an additional libc with the right options ?
On Thu, 15 Jan 2009, Alan Cox wrote:
> > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > so why not include it like with LL/SC for MIPS?
>
> Why not just ship an additional libc with the right options ?
Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs
and LL/SC is always used. For the i386 the situation seems worse yet as
for pre-i486 CPUs a generic C implementation of compare-and-exchange is
used guaranteeing silent thread unsafety. :(
IMO, a kernel emulation of CMPXCHG and XADD (both are used by
sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
guaranteeing UP atomicity would be a cheap way to provide long-term i386
userland support with little burden for both Linux and respective user
software maintainers. Certainly it adds some bloat to the kernel, but I
think it is not an option that should be outright dismissed without
consideration.
Maciej
* Maciej W. Rozycki <[email protected]> wrote:
> On Thu, 15 Jan 2009, Alan Cox wrote:
>
> > > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > > so why not include it like with LL/SC for MIPS?
> >
> > Why not just ship an additional libc with the right options ?
>
> Does not work for MIPS as glibc has no equivalent code for pre-LL/SC
> CPUs and LL/SC is always used. For the i386 the situation seems worse
> yet as for pre-i486 CPUs a generic C implementation of
> compare-and-exchange is used guaranteeing silent thread unsafety. :(
>
> IMO, a kernel emulation of CMPXCHG and XADD (both are used by
> sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
> guaranteeing UP atomicity would be a cheap way to provide long-term i386
> userland support with little burden for both Linux and respective user
> software maintainers. Certainly it adds some bloat to the kernel, but I
> think it is not an option that should be outright dismissed without
> consideration.
patches are welcome ...
Ingo
On Thu, 2009-01-15 14:15:56 +0000, Maciej W. Rozycki <[email protected]> wrote:
> On Thu, 15 Jan 2009, Alan Cox wrote:
> > > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > > so why not include it like with LL/SC for MIPS?
> >
> > Why not just ship an additional libc with the right options ?
>
> Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs
> and LL/SC is always used. For the i386 the situation seems worse yet as
> for pre-i486 CPUs a generic C implementation of compare-and-exchange is
> used guaranteeing silent thread unsafety. :(
>
> IMO, a kernel emulation of CMPXCHG and XADD (both are used by
> sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
> guaranteeing UP atomicity would be a cheap way to provide long-term i386
> userland support with little burden for both Linux and respective user
> software maintainers. Certainly it adds some bloat to the kernel, but I
> think it is not an option that should be outright dismissed without
> consideration.
I just searched for the old patch, but couldn't find it ad hoc. (But
it must be somewhere, at least in the archives, I guess?)
The kernel emulator has the benefit of no overhead when not switched
on, and low-to-no overhead when not being used (i386 capable kernel on
i486 hardware).
Heck, I'd dig out my two test systems and give them a try with current
Debian unstable. Should be fun with four to eight megabytes of RAM.
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett.
the second : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?)
00:00 <@jbglaw> jever2: *patsch*
00:01 <@jever2> *aua*, wofür, Gedanken sind frei!
00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus!
00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet!
> userland support with little burden for both Linux and respective user
> software maintainers. Certainly it adds some bloat to the kernel, but I
> think it is not an option that should be outright dismissed without
> consideration.
Nobody normally builds for 386 (and you need the big FPU emulator etc too
and pay a big penalty for the lack of working WP bits) so it wouldn't be
a big penalty if you can actually find an i386 user any more ;)
On Thu, Jan 15, 2009 at 3:20 PM, Jan-Benedict Glaw <[email protected]> wrote:
> On Thu, 2009-01-15 14:15:56 +0000, Maciej W. Rozycki <[email protected]> wrote:
>> On Thu, 15 Jan 2009, Alan Cox wrote:
>> > > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
>> > > so why not include it like with LL/SC for MIPS?
>> >
>> > Why not just ship an additional libc with the right options ?
>>
>> Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs
>> and LL/SC is always used. For the i386 the situation seems worse yet as
>> for pre-i486 CPUs a generic C implementation of compare-and-exchange is
>> used guaranteeing silent thread unsafety. :(
>>
>> IMO, a kernel emulation of CMPXCHG and XADD (both are used by
>> sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
>> guaranteeing UP atomicity would be a cheap way to provide long-term i386
>> userland support with little burden for both Linux and respective user
>> software maintainers. Certainly it adds some bloat to the kernel, but I
>> think it is not an option that should be outright dismissed without
>> consideration.
>
> I just searched for the old patch, but couldn't find it ad hoc. (But
> it must be somewhere, at least in the archives, I guess?)
here http://thread.gmane.org/gmane.linux.kernel/205839, but should be
securized (use get_user() )
Regards
> The kernel emulator has the benefit of no overhead when not switched
> on, and low-to-no overhead when not being used (i386 capable kernel on
> i486 hardware).
>
> Heck, I'd dig out my two test systems and give them a try with current
> Debian unstable. Should be fun with four to eight megabytes of RAM.
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw [email protected] +49-172-7608481
> Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett.
> the second : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, wie fr?her meine Kinder?)
> 00:00 <@jbglaw> jever2: *patsch*
> 00:01 <@jever2> *aua*, wof?r, Gedanken sind frei!
> 00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus!
> 00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJb0Y/Hb1edYOZ4bsRAnEeAJ9JkaqmDFOGp1uPNzBe4qeSgl19dQCeI123
> c4oTq/pPCaUPcdJp3a/GsbU=
> =wHyn
> -----END PGP SIGNATURE-----
>
>
On Thu, 15 Jan 2009, Alan Cox wrote:
> > userland support with little burden for both Linux and respective user
> > software maintainers. Certainly it adds some bloat to the kernel, but I
> > think it is not an option that should be outright dismissed without
> > consideration.
>
> Nobody normally builds for 386 (and you need the big FPU emulator etc too
> and pay a big penalty for the lack of working WP bits) so it wouldn't be
> a big penalty if you can actually find an i386 user any more ;)
You can actually escape the FPU emulator if you have a proper computer
(an i386/80287 combo, anyone? ;) -- we've got it right actually :) ), but
the rest and overall I agree with you. And I think i386-class cores can
be still seen in some embedded applications, so there may be non-epsilon
interest yet.
Maciej
On Thu, 2009-01-15 13:32:52 +0000, Alan Cox <[email protected]> wrote:
> > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > so why not include it like with LL/SC for MIPS?
>
> Why not just ship an additional libc with the right options ?
Due to another historic bug, which created libcs targeted for i386
containing the locking code for i486, as I was told back when I first
showed interest for real i386 hardware.
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: Friends are relatives you make for yourself.
the second :
Maciej W. Rozycki wrote:
>
> You can actually escape the FPU emulator if you have a proper computer
> (an i386/80287 combo, anyone? ;) -- we've got it right actually :) ), but
> the rest and overall I agree with you. And I think i386-class cores can
> be still seen in some embedded applications, so there may be non-epsilon
> interest yet.
>
I did run Linux way back when on a 16 MHz 80386/80387 combo. All the
memory was on the ISA bus, too. It ran at a whopping 0.57 BogoMIPS, and
we still used it as a server.
-hpa
>
> * Maciej W. Rozycki <[email protected]> wrote:
>
> > On Thu, 15 Jan 2009, Alan Cox wrote:
> >
> > > > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > > > so why not include it like with LL/SC for MIPS?
> > >
> > > Why not just ship an additional libc with the right options ?
> >
> > Does not work for MIPS as glibc has no equivalent code for pre-LL/SC
> > CPUs and LL/SC is always used. For the i386 the situation seems worse
> > yet as for pre-i486 CPUs a generic C implementation of
> > compare-and-exchange is used guaranteeing silent thread unsafety. :(
> >
> > IMO, a kernel emulation of CMPXCHG and XADD (both are used by
> > sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
> > guaranteeing UP atomicity would be a cheap way to provide long-term i386
> > userland support with little burden for both Linux and respective user
> > software maintainers. Certainly it adds some bloat to the kernel, but I
> > think it is not an option that should be outright dismissed without
> > consideration.
>
> patches are welcome ...
Hehe, I guess the only long-term solution is to get shiny old 386 as a
part of Ingo's test farm ;-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 2009-01-16 10:00:02 +0100, Pavel Machek <[email protected]> wrote:
> > patches are welcome ...
>
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).
:-D I'm currently cleaning up the flat, 'll try to dig out the old
patch tonight. Maybe I can play with it a bit on my original i386
hardware. (I've already tested it, it still powers on and boots up
that ancient debian version. Using a 20GB (right, gigabytes) HDD.)
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: http://catb.org/~esr/faqs/smart-questions.html
the second :
On 016, 01 16, 2009 at 10:00:02AM +0100, Pavel Machek wrote:
> >
> > * Maciej W. Rozycki <[email protected]> wrote:
> >
> > > On Thu, 15 Jan 2009, Alan Cox wrote:
> > >
> > > > > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > > > > so why not include it like with LL/SC for MIPS?
> > > >
> > > > Why not just ship an additional libc with the right options ?
> > >
> > > Does not work for MIPS as glibc has no equivalent code for pre-LL/SC
> > > CPUs and LL/SC is always used. For the i386 the situation seems worse
> > > yet as for pre-i486 CPUs a generic C implementation of
> > > compare-and-exchange is used guaranteeing silent thread unsafety. :(
> > >
> > > IMO, a kernel emulation of CMPXCHG and XADD (both are used by
> > > sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
> > > guaranteeing UP atomicity would be a cheap way to provide long-term i386
> > > userland support with little burden for both Linux and respective user
> > > software maintainers. Certainly it adds some bloat to the kernel, but I
> > > think it is not an option that should be outright dismissed without
> > > consideration.
> >
> > patches are welcome ...
>
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).
It's not so difficult BTW, i386EX CPUs are still used in embedded world.
Example: http://www.embeddedarm.com/products/board-detail.php?product=TS-3300
It even has ethernet and price is reasonable (for embedded board of course) :)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
* Pavel Machek <[email protected]> wrote:
> >
> > * Maciej W. Rozycki <[email protected]> wrote:
> >
> > > On Thu, 15 Jan 2009, Alan Cox wrote:
> > >
> > > > > UP emulation of CMPXCHG and XADD for userland should be rather trivial,
> > > > > so why not include it like with LL/SC for MIPS?
> > > >
> > > > Why not just ship an additional libc with the right options ?
> > >
> > > Does not work for MIPS as glibc has no equivalent code for pre-LL/SC
> > > CPUs and LL/SC is always used. For the i386 the situation seems worse
> > > yet as for pre-i486 CPUs a generic C implementation of
> > > compare-and-exchange is used guaranteeing silent thread unsafety. :(
> > >
> > > IMO, a kernel emulation of CMPXCHG and XADD (both are used by
> > > sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
> > > guaranteeing UP atomicity would be a cheap way to provide long-term i386
> > > userland support with little burden for both Linux and respective user
> > > software maintainers. Certainly it adds some bloat to the kernel, but I
> > > think it is not an option that should be outright dismissed without
> > > consideration.
> >
> > patches are welcome ...
>
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).
hehe :) Alas, Thomas has one and occasionally boots the kernel on it.
Ingo
Pavel Machek wrote:
>
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).
> Pavel
Emulators are faster.
-hpa