> > Be careful there. CMOV is an optional instruction. gcc is arguably wrong
> > in using cmov in '686' mode. Building libs with cmov makes sense though
> > especially for the PIV with its ridiculously long pipeline
>
> It is just a matter how you define "686 mode", otherwise the very concept
>
> Yes, the big 686 optimization is CMOV, and that one is
> ultra-pervasive.
Be careful there. CMOV is an optional instruction. gcc is arguably wrong
in using cmov in '686' mode. Building libs with cmov makes sense though
especially for the PIV with its ridiculously long pipeline
>
-
To
Alan Cox wrote:
>
> > Yes, the big 686 optimization is CMOV, and that one is
> > ultra-pervasive.
>
> Be careful there. CMOV is an optional instruction. gcc is arguably wrong
> in using cmov in '686' mode. Building libs with cmov makes sense though
> especially for the PIV with its ridiculously
> You need sterner testing stuff :) I hit the BUG at the end of rwsem_wake()
> in about a second running rwsem-4. Removed the BUG and everything stops
> in D state.
>
> Grab rwsem-4 from
>
> http://www.uow.edu.au/~andrewm/linux/rwsem.tar.gz
>
> It's very simple. But running fully
On Wed, 11 Apr 2001, David Howells wrote:
>
> > These numbers are infinity :)
>
> I know, but I think Linus may be happy with the resolution for the moment. It
> can be extended later by siphoning off excess quantities of waiters into a
> separate counter (as is done now) and by making the
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > (the other 686 optimizations like memcpy also work on 386)
>
> They would still be needed. The 686 built
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Note that the "fixup" approach is not necessarily very painful at all,
> from a performance standpoint (either on 386 or on newer CPU's). It's not
> really that hard to just
Andrew Morton wrote:
> I think that's a very good approach. Sure, it's suboptimal when there
> are three or more waiters (and they're the right type and order). But
> that never happens. Nice design idea.
Cheers.
> These numbers are infinity :)
I know, but I think Linus may be happy with
David Howells wrote:
>
> Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> simple in the way it works.
>
> The lock counter is dealt with as two semi-independent words: the LSW is the
> number of active (granted) locks, and the MSW, if negated, is the number of
>
On Wed, 11 Apr 2001, David Howells wrote:
> Can CONFIG_X86_XADD be equated to CONFIG_X86_CMPXCHG?
Yes. Modulo very early i486s which used incorrect opcodes for cmpxchg.
They can probably be safely ignored.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
> It's currently done this way, ld-linux.so looks in a special "686" path when
> the ELF vector mentions it, otherwise normal path. There is a special 686
> version of glibc and linuxthread. Just it's a very complicated and disk
> space chewing solution for a simple problem (some distributions
> My reasoning is that who uses a 386 is not interested in speed, so a little
> bit more slowness is not that bad.
>
> You realize that the alternative for distributions is to drop 386 support
> completely?
Rubbish. Mandrake and Red Hat have been shipping multiple kernel images,
multiple gzips
> > 386 could use a simpler setup and is non SMP
>
> The idea was to have a `generic' kernel that works on all architectures.
> If you drop 386 support much is better already.
Having the 386 non SMP only means you dont have to worry about this. We dont
currently support an SMP kernel that boots
Can CONFIG_X86_XADD be equated to CONFIG_X86_CMPXCHG?
David
-
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/
Can CONFIG_X86_XADD be equated to CONFIG_X86_CMPXCHG?
David
-
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/
386 could use a simpler setup and is non SMP
The idea was to have a `generic' kernel that works on all architectures.
If you drop 386 support much is better already.
Having the 386 non SMP only means you dont have to worry about this. We dont
currently support an SMP kernel that boots
My reasoning is that who uses a 386 is not interested in speed, so a little
bit more slowness is not that bad.
You realize that the alternative for distributions is to drop 386 support
completely?
Rubbish. Mandrake and Red Hat have been shipping multiple kernel images,
multiple gzips and
It's currently done this way, ld-linux.so looks in a special "686" path when
the ELF vector mentions it, otherwise normal path. There is a special 686
version of glibc and linuxthread. Just it's a very complicated and disk
space chewing solution for a simple problem (some distributions are
On Wed, 11 Apr 2001, David Howells wrote:
Can CONFIG_X86_XADD be equated to CONFIG_X86_CMPXCHG?
Yes. Modulo very early i486s which used incorrect opcodes for cmpxchg.
They can probably be safely ignored.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
David Howells wrote:
Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.
The lock counter is dealt with as two semi-independent words: the LSW is the
number of active (granted) locks, and the MSW, if negated, is the number of
active
Andrew Morton wrote:
I think that's a very good approach. Sure, it's suboptimal when there
are three or more waiters (and they're the right type and order). But
that never happens. Nice design idea.
Cheers.
These numbers are infinity :)
I know, but I think Linus may be happy with the
Followup to: [EMAIL PROTECTED]
By author:Linus Torvalds [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Note that the "fixup" approach is not necessarily very painful at all,
from a performance standpoint (either on 386 or on newer CPU's). It's not
really that hard to just replace the
Followup to: [EMAIL PROTECTED]
By author:Alan Cox [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
(the other 686 optimizations like memcpy also work on 386)
They would still be needed. The 686 built glibc
On Wed, 11 Apr 2001, David Howells wrote:
These numbers are infinity :)
I know, but I think Linus may be happy with the resolution for the moment. It
can be extended later by siphoning off excess quantities of waiters into a
separate counter (as is done now) and by making the access
You need sterner testing stuff :) I hit the BUG at the end of rwsem_wake()
in about a second running rwsem-4. Removed the BUG and everything stops
in D state.
Grab rwsem-4 from
http://www.uow.edu.au/~andrewm/linux/rwsem.tar.gz
It's very simple. But running fully in-kernel
Alan Cox wrote:
Yes, the big 686 optimization is CMOV, and that one is
ultra-pervasive.
Be careful there. CMOV is an optional instruction. gcc is arguably wrong
in using cmov in '686' mode. Building libs with cmov makes sense though
especially for the PIV with its ridiculously long
Yes, the big 686 optimization is CMOV, and that one is
ultra-pervasive.
Be careful there. CMOV is an optional instruction. gcc is arguably wrong
in using cmov in '686' mode. Building libs with cmov makes sense though
especially for the PIV with its ridiculously long pipeline
-
To
Be careful there. CMOV is an optional instruction. gcc is arguably wrong
in using cmov in '686' mode. Building libs with cmov makes sense though
especially for the PIV with its ridiculously long pipeline
It is just a matter how you define "686 mode", otherwise the very concept
is
On Tue, Apr 10, 2001 at 06:12:12PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 11 Apr 2001, Andi Kleen wrote:
> >
> > Fixup for user space is probably not that nice (CMPXCHG is used there by
> > linuxthreads)
>
> In user space I'm not convinced that you couldn't do the same thing
> equally well
On Wed, 11 Apr 2001, Andi Kleen wrote:
>
> Fixup for user space is probably not that nice (CMPXCHG is used there by
> linuxthreads)
In user space I'm not convinced that you couldn't do the same thing
equally well by just having the proper dynamically linked library. You'd
not get in-lined
On Tue, Apr 10, 2001 at 05:55:09PM -0700, Linus Torvalds wrote:
> Note that the "fixup" approach is not necessarily very painful at all,
> from a performance standpoint (either on 386 or on newer CPU's). It's not
> really that hard to just replace the instruction in the "undefined
> instruction"
On Wed, Apr 11, 2001 at 02:56:32AM +0200, David Weinehall wrote:
> My reasoning is that the choice of computer is a direct function of
> your financial situation. I can get hold of a lot of 386's/486's, but
> however old a Pentium may be, people are still reluctant to give away
> those. Doing the
On Wed, Apr 11, 2001 at 02:20:28AM +0200, Andi Kleen wrote:
> On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
> > >
> > > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > > (the other 686 optimizations like memcpy also work on 386)
> >
> > But the code
On Wed, 11 Apr 2001, David Weinehall wrote:
> >
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > (the other 686 optimizations like memcpy also work on 386)
>
> But the code would be much slower, and it's on 386's and similarly
> slow beasts you need every cycle you can
Sequent Symmetry machinses supported SMP on i486 and even i386 going back
to the original 16MHz 386 processors. You could put up to 30 in a system.
I do not, however, envisage anyone porting Linux to these any time soon.
The hardware is just too "unusual" for it to be feasible. The later Symmetry
On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
> >
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > (the other 686 optimizations like memcpy also work on 386)
>
> But the code would be much slower, and it's on 386's and similarly
> slow beasts you
On Wed, Apr 11, 2001 at 02:00:58AM +0200, Andi Kleen wrote:
> On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
> > > I guess 386 could live with an exception handler that emulates it.
> >
> > 386 could use a simpler setup and is non SMP
>
> The idea was to have a `generic' kernel that
On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
> > I guess 386 could live with an exception handler that emulates it.
>
> 386 could use a simpler setup and is non SMP
The idea was to have a `generic' kernel that works on all architectures.
If you drop 386 support much is better
> I guess 386 could live with an exception handler that emulates it.
386 could use a simpler setup and is non SMP
> (BTW an generic exception handler for CMPXCHG would also be very useful
> for glibc -- currently it has special checking code for 386 in its mutexes)
> The 386 are so slow that
> The current way of doing things on x86 -- essentially selecting a
> minimal level of CPU support -- is nice for vendors like Mandrake who
That isnt how the current x86 one works. It just sort of looks like that
for a common subset.
-
To unsubscribe from this list: send the line "unsubscribe
> That's no problem if we make this SMP-specific - I doubt anybody actually
> uses SMP on i486's even if the machines exist, as I think they all had
They do. There are two (total world wide) 486 SMP users I know about and they
mostly do it to be awkward ;)
> special glue logic that Linux would
On Tue, 10 Apr 2001, Andi Kleen wrote:
>
> I guess 386 could live with an exception handler that emulates it.
That approach is fine, although I'd personally prefer to take the
exception just once and just rewrite the instuction as a "call". The
places that need xadd would have to follow some
On Tue, Apr 10, 2001 at 12:42:07PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 10 Apr 2001, David Howells wrote:
> >
> > Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> > simple in the way it works.
>
> XADD only works on Pentium+.
My Intel manual says it 486+:
Linus Torvalds wrote:
> That's no problem if we make this SMP-specific - I doubt anybody actually
> uses SMP on i486's even if the machines exist, as I think they all had
> special glue logic that Linux would have trouble with anyway. But the
> advantages of being able to use one generic kernel
On Tue, 10 Apr 2001, David Howells wrote:
>
> Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> simple in the way it works.
XADD only works on Pentium+.
That's no problem if we make this SMP-specific - I doubt anybody actually
uses SMP on i486's even if the
Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.
The lock counter is dealt with as two semi-independent words: the LSW is the
number of active (granted) locks, and the MSW, if negated, is the number of
active writers (0 or 1) plus the
Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.
The lock counter is dealt with as two semi-independent words: the LSW is the
number of active (granted) locks, and the MSW, if negated, is the number of
active writers (0 or 1) plus the
On Tue, 10 Apr 2001, David Howells wrote:
Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.
XADD only works on Pentium+.
That's no problem if we make this SMP-specific - I doubt anybody actually
uses SMP on i486's even if the machines
Linus Torvalds wrote:
That's no problem if we make this SMP-specific - I doubt anybody actually
uses SMP on i486's even if the machines exist, as I think they all had
special glue logic that Linux would have trouble with anyway. But the
advantages of being able to use one generic kernel that
On Tue, Apr 10, 2001 at 12:42:07PM -0700, Linus Torvalds wrote:
On Tue, 10 Apr 2001, David Howells wrote:
Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.
XADD only works on Pentium+.
My Intel manual says it 486+:
``
On Tue, 10 Apr 2001, Andi Kleen wrote:
I guess 386 could live with an exception handler that emulates it.
That approach is fine, although I'd personally prefer to take the
exception just once and just rewrite the instuction as a "call". The
places that need xadd would have to follow some
That's no problem if we make this SMP-specific - I doubt anybody actually
uses SMP on i486's even if the machines exist, as I think they all had
They do. There are two (total world wide) 486 SMP users I know about and they
mostly do it to be awkward ;)
special glue logic that Linux would
The current way of doing things on x86 -- essentially selecting a
minimal level of CPU support -- is nice for vendors like Mandrake who
That isnt how the current x86 one works. It just sort of looks like that
for a common subset.
-
To unsubscribe from this list: send the line "unsubscribe
I guess 386 could live with an exception handler that emulates it.
386 could use a simpler setup and is non SMP
(BTW an generic exception handler for CMPXCHG would also be very useful
for glibc -- currently it has special checking code for 386 in its mutexes)
The 386 are so slow that
On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
I guess 386 could live with an exception handler that emulates it.
386 could use a simpler setup and is non SMP
The idea was to have a `generic' kernel that works on all architectures.
If you drop 386 support much is better already.
On Wed, Apr 11, 2001 at 02:00:58AM +0200, Andi Kleen wrote:
On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
I guess 386 could live with an exception handler that emulates it.
386 could use a simpler setup and is non SMP
The idea was to have a `generic' kernel that works on
On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
(the other 686 optimizations like memcpy also work on 386)
But the code would be much slower, and it's on 386's and similarly
slow beasts you need every
Sequent Symmetry machinses supported SMP on i486 and even i386 going back
to the original 16MHz 386 processors. You could put up to 30 in a system.
I do not, however, envisage anyone porting Linux to these any time soon.
The hardware is just too "unusual" for it to be feasible. The later Symmetry
On Wed, 11 Apr 2001, David Weinehall wrote:
Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
(the other 686 optimizations like memcpy also work on 386)
But the code would be much slower, and it's on 386's and similarly
slow beasts you need every cycle you can get, NOT
On Wed, Apr 11, 2001 at 02:20:28AM +0200, Andi Kleen wrote:
On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
(the other 686 optimizations like memcpy also work on 386)
But the code would be much
On Wed, Apr 11, 2001 at 02:56:32AM +0200, David Weinehall wrote:
My reasoning is that the choice of computer is a direct function of
your financial situation. I can get hold of a lot of 386's/486's, but
however old a Pentium may be, people are still reluctant to give away
those. Doing the
On Tue, Apr 10, 2001 at 05:55:09PM -0700, Linus Torvalds wrote:
Note that the "fixup" approach is not necessarily very painful at all,
from a performance standpoint (either on 386 or on newer CPU's). It's not
really that hard to just replace the instruction in the "undefined
instruction"
On Wed, 11 Apr 2001, Andi Kleen wrote:
Fixup for user space is probably not that nice (CMPXCHG is used there by
linuxthreads)
In user space I'm not convinced that you couldn't do the same thing
equally well by just having the proper dynamically linked library. You'd
not get in-lined lock
On Tue, Apr 10, 2001 at 06:12:12PM -0700, Linus Torvalds wrote:
On Wed, 11 Apr 2001, Andi Kleen wrote:
Fixup for user space is probably not that nice (CMPXCHG is used there by
linuxthreads)
In user space I'm not convinced that you couldn't do the same thing
equally well by just
64 matches
Mail list logo
