Linus Torvalds wrote:
> For i386 and i486, there is no reason to try to maintain a complex fast
> case. The machines are unquestionably going away - we should strive to not
> burden them unnecessarily, but we should _not_ try to save two cycles.
...
> Icache is also precious on the 386, which has
Linus Torvalds wrote:
For i386 and i486, there is no reason to try to maintain a complex fast
case. The machines are unquestionably going away - we should strive to not
burden them unnecessarily, but we should _not_ try to save two cycles.
...
Icache is also precious on the 386, which has no
On Mon, Apr 23, 2001 at 06:27:23PM -0500, Bob McElrath wrote:
> Well, take that back, I just got it to hang. Again, this is 2.4.4pre3
> with alpha-numa-3 and rwsem-generic-4. I saw it upon starting mozilla.
> I also saw some scary filesystem errors that may or may not be related:
> Apr 23
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> > I'm at 2 days uptime now, and have not seen the process-table-hang.
> > Looks like this fixed it. Previously I would get a hang in the first
> > day or so. I'm using your alpha-numa-3
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
I'm at 2 days uptime now, and have not seen the process-table-hang.
Looks like this fixed it. Previously I would get a hang in the first
day or so. I'm using your alpha-numa-3 and
On Mon, Apr 23, 2001 at 06:27:23PM -0500, Bob McElrath wrote:
Well, take that back, I just got it to hang. Again, this is 2.4.4pre3
with alpha-numa-3 and rwsem-generic-4. I saw it upon starting mozilla.
I also saw some scary filesystem errors that may or may not be related:
Apr 23
On Sat, 21 Apr 2001, Russell King wrote:
>
> Erm, spin_lock()? What if up_read or up_write gets called from interrupt
> context (is this allowed)?
Currently that is not allowed.
We allow it for regular semaphores, but not for rw-semaphores.
We may some day have to revisit that issue, but I
On Sat, Apr 21, 2001 at 03:37:42PM +0100, Russell King wrote:
> On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> > On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > > I would suggest the following:
> > >
> > > - the generic semaphores should use the lock
On Sat, Apr 21, 2001 at 03:37:05PM +0100, [EMAIL PROTECTED] wrote:
> Andrea Arcangeli writes:
> > That it is allowed by my generic code that does spin_lock_irq in down_* and
> > spin_lock_irqsave in up_* but it's disallowed by the weaker semantics of the
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > I would suggest the following:
> >
> > - the generic semaphores should use the lock that already exists in the
> >wait-queue as the semaphore spinlock.
>
Andrea Arcangeli writes:
> That it is allowed by my generic code that does spin_lock_irq in down_* and
> spin_lock_irqsave in up_* but it's disallowed by the weaker semantics of the
> generic and x86 semaphores 2.4.4pre[2345] (or + David's last patch).
Hang on, who's code is in 2.4.4-pre5? It
On Sat, Apr 21, 2001 at 03:17:37PM +0100, Russell King wrote:
> On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> > On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > > I would suggest the following:
> > >
> > > - the generic semaphores should use the lock
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > I would suggest the following:
> >
> > - the generic semaphores should use the lock that already exists in the
> >wait-queue as the semaphore spinlock.
>
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> I would suggest the following:
>
> - the generic semaphores should use the lock that already exists in the
>wait-queue as the semaphore spinlock.
Ok, that is what my generic code does.
> - the generic semaphores should
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
I would suggest the following:
- the generic semaphores should use the lock that already exists in the
wait-queue as the semaphore spinlock.
Ok, that is what my generic code does.
- the generic semaphores should _not_
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
I would suggest the following:
- the generic semaphores should use the lock that already exists in the
wait-queue as the semaphore spinlock.
Ok, that
On Sat, Apr 21, 2001 at 03:17:37PM +0100, Russell King wrote:
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
I would suggest the following:
- the generic semaphores should use the lock that already
Andrea Arcangeli writes:
That it is allowed by my generic code that does spin_lock_irq in down_* and
spin_lock_irqsave in up_* but it's disallowed by the weaker semantics of the
generic and x86 semaphores 2.4.4pre[2345] (or + David's last patch).
Hang on, who's code is in 2.4.4-pre5? It
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
I would suggest the following:
- the generic semaphores should use the lock that already exists in the
wait-queue as the semaphore spinlock.
Ok, that
On Sat, Apr 21, 2001 at 03:37:05PM +0100, [EMAIL PROTECTED] wrote:
Andrea Arcangeli writes:
That it is allowed by my generic code that does spin_lock_irq in down_* and
spin_lock_irqsave in up_* but it's disallowed by the weaker semantics of the
On Sat, Apr 21, 2001 at 03:37:42PM +0100, Russell King wrote:
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
I would suggest the following:
- the generic semaphores should use the lock that already
On Sat, 21 Apr 2001, Russell King wrote:
Erm, spin_lock()? What if up_read or up_write gets called from interrupt
context (is this allowed)?
Currently that is not allowed.
We allow it for regular semaphores, but not for rw-semaphores.
We may some day have to revisit that issue, but I
On Fri, 20 Apr 2001, Andrea Arcangeli wrote:
>
> While dropping the list_empty check to speed up the fast path I faced the same
> complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the wheel I
> read how the problem was solved in 2.4.4pre4.
I would suggest the following:
- the
On Fri, Apr 20, 2001 at 09:23:47AM +0100, David Howells wrote:
> Andrea seems to have changed his mind on the non-inlining in the generic case.
I changed my mind because if you benchmark the fast path you will do it without
running out of icache (basically only down_* and up_* will be in the
On Fri, Apr 20, 2001 at 03:42:15AM +0200, Andrea Arcangeli wrote:
> I'm uncertain if I should drop the list_empty() check from the fast path and if
While dropping the list_empty check to speed up the fast path I faced the same
complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the
> About the benchmark you wrote it looks good measure to me, thanks.
As with all benchmarks, take with one pinch of salt and two of Mindcraft:-)
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
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I think Andrea is right. Although this file seems to be entirely
> old-fashioned and should never be used, right?
I presume you're talking about "include/asm-i386/rwsem-spin.h"... If so,
Andrea is right, there is a bug in it (repeated a number of
Linus Torvalds [EMAIL PROTECTED] wrote:
I think Andrea is right. Although this file seems to be entirely
old-fashioned and should never be used, right?
I presume you're talking about "include/asm-i386/rwsem-spin.h"... If so,
Andrea is right, there is a bug in it (repeated a number of times),
About the benchmark you wrote it looks good measure to me, thanks.
As with all benchmarks, take with one pinch of salt and two of Mindcraft:-)
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
On Fri, Apr 20, 2001 at 03:42:15AM +0200, Andrea Arcangeli wrote:
I'm uncertain if I should drop the list_empty() check from the fast path and if
While dropping the list_empty check to speed up the fast path I faced the same
complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the
On Fri, 20 Apr 2001, Andrea Arcangeli wrote:
While dropping the list_empty check to speed up the fast path I faced the same
complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the wheel I
read how the problem was solved in 2.4.4pre4.
I would suggest the following:
- the
On Fri, Apr 20, 2001 at 09:23:47AM +0100, David Howells wrote:
Andrea seems to have changed his mind on the non-inlining in the generic case.
I changed my mind because if you benchmark the fast path you will do it without
running out of icache (basically only down_* and up_* will be in the
On Fri, Apr 20, 2001 at 12:28:09AM +0100, D . W . Howells wrote:
> I benchmarked four different environments:
>
> (1) 2.4.4-pre3 + Andrea's generic rwsem patch
> (2) 2.4.4-pre4 using XADD to implement the rwsems
> (3) same as (2) but with a tweak to make rwsem_wake() less fair
You asked for some benchmarks Andrea, so I've obtained some.
The set of test modules can be found at:
ftp://infradead.org/pub/people/dwh/rwsem-test.tar.bz2
(This also includes rwsem-stat.txt which has a copy of the benchmark results
in as well)
There are six test programs. They can
On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> I'm at 2 days uptime now, and have not seen the process-table-hang.
> Looks like this fixed it. Previously I would get a hang in the first
> day or so. I'm using your alpha-numa-3 and rwsem-generic-4 against
> 2.4.4pre3.
good,
Bob McElrath [[EMAIL PROTECTED]] wrote:
> Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> >
> > So please try to reproduce the hang with 2.4.4pre3 with those two
> > patches applied:
> >
> >
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
> >
Bob McElrath [[EMAIL PROTECTED]] wrote:
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
So please try to reproduce the hang with 2.4.4pre3 with those two
patches applied:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
I'm at 2 days uptime now, and have not seen the process-table-hang.
Looks like this fixed it. Previously I would get a hang in the first
day or so. I'm using your alpha-numa-3 and rwsem-generic-4 against
2.4.4pre3.
good, thanks
You asked for some benchmarks Andrea, so I've obtained some.
The set of test modules can be found at:
ftp://infradead.org/pub/people/dwh/rwsem-test.tar.bz2
(This also includes rwsem-stat.txt which has a copy of the benchmark results
in as well)
There are six test programs. They can
On Fri, Apr 20, 2001 at 12:28:09AM +0100, D . W . Howells wrote:
I benchmarked four different environments:
(1) 2.4.4-pre3 + Andrea's generic rwsem patch
(2) 2.4.4-pre4 using XADD to implement the rwsems
(3) same as (2) but with a tweak to make rwsem_wake() less fair
On Wed, Apr 18, 2001 at 12:54:41AM +0100, D . W . Howells wrote:
> > It is 36bytes. and on 64bit archs the difference is going to be less.
>
> You're right - I can't add up (must be too late at night), and I was looking
> at wait_queue not wait_queue_head. I suppose that means my
On Wed, Apr 18, 2001 at 12:54:41AM +0100, D . W . Howells wrote:
It is 36bytes. and on 64bit archs the difference is going to be less.
You're right - I can't add up (must be too late at night), and I was looking
at wait_queue not wait_queue_head. I suppose that means my implementations
> It is 36bytes. and on 64bit archs the difference is going to be less.
You're right - I can't add up (must be too late at night), and I was looking
at wait_queue not wait_queue_head. I suppose that means my implementations
are then 20 and 16 bytes respectively.
On 64-bit archs the
On Tue, Apr 17, 2001 at 10:48:02PM +0100, D . W . Howells wrote:
> I disagree... you want such primitives to be as efficient as possible. The
> whole point of having asm/.h files is that you can stuff them full of
> dirty tricks specific to certain architectures.
Of course you always have
On Tue, Apr 17, 2001 at 11:29:23PM +0200, Christoph Hellwig wrote:
> Yes! All the objects in export-objs only get additional depencies in
> Rules.make - but if they do not get compiled at all that depencies won't
> matter either. All other makefile work this way, btw.
ok thanks for the confirm.
> I am sure ppc couldn't race (at least unless up_read/up_write were excuted
> from irq/softnet context and that never happens in 2.4.4pre3, see below ;).
This is not actually using the rwsem code I wrote at the moment.
> And incidentally the above is what (I guess Richard) did on the alpha
Hi Andrea,
In article <[EMAIL PROTECTED]> you wrote:
> I didn't exported rwsem.c if CONFIG_RWSEM_GENERIC is set to n as suggested
> by Christoph yet because the old code couldn't be buggy and it's not obvious to
> me that the other way around is correct (Christoph are you sure we can export an
>
On Tue, Apr 17, 2001 at 08:18:57PM +0100, D . W . Howells wrote:
> Andrea,
>
> > As said the design of the framework to plugin per-arch rwsem implementation
> > isn't flexible enough and the generic spinlocks are as well broken, try to
> > use them if you can (yes I tried that for the alpha,
Andrea,
> As said the design of the framework to plugin per-arch rwsem implementation
> isn't flexible enough and the generic spinlocks are as well broken, try to
> use them if you can (yes I tried that for the alpha, it was just a mess and
> it was more productive to rewrite than to fix).
On Tue, Apr 17, 2001 at 05:59:13PM +0100, David Howells wrote:
> Andrea,
>
> How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
2.4.4pre3 from kernel.org.
> You seem to have removed all the optimised i386 rwsem stuff... Did it not work
> for you?
As said the design
Andrea,
How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
You seem to have removed all the optimised i386 rwsem stuff... Did it not work
for you?
> (the generic rwsemaphores in those kernels is broken, try to use them in
> other archs or x86 and you will notice) and
In article <[EMAIL PROTECTED]> you wrote:
> My generic rwsem should be also cleaner and faster than the generic ones in
> 2.4.4pre3 and they can be turned off completly so an architecture can really
> takeover with its own asm implementation (while with the 2.4.4pre3 design this
> is obviously
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
>
> So please try to reproduce the hang with 2.4.4pre3 with those two
> patches applied:
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
>
On Fri, Apr 13, 2001 at 08:48:05AM -0500, Bob McElrath wrote:
> Alan Cox [[EMAIL PROTECTED]] wrote:
> > > (But since the X server shouldn't have the ability to corrupt the
> > > kernel's process list, there has to be a problem in the kernel
> > > somewhere)
> >
> > The X server has enough
On Fri, Apr 13, 2001 at 08:48:05AM -0500, Bob McElrath wrote:
Alan Cox [[EMAIL PROTECTED]] wrote:
(But since the X server shouldn't have the ability to corrupt the
kernel's process list, there has to be a problem in the kernel
somewhere)
The X server has enough priviledge to
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
So please try to reproduce the hang with 2.4.4pre3 with those two
patches applied:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
In article [EMAIL PROTECTED] you wrote:
My generic rwsem should be also cleaner and faster than the generic ones in
2.4.4pre3 and they can be turned off completly so an architecture can really
takeover with its own asm implementation (while with the 2.4.4pre3 design this
is obviously not
Andrea,
How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
You seem to have removed all the optimised i386 rwsem stuff... Did it not work
for you?
(the generic rwsemaphores in those kernels is broken, try to use them in
other archs or x86 and you will notice) and I
On Tue, Apr 17, 2001 at 05:59:13PM +0100, David Howells wrote:
Andrea,
How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
2.4.4pre3 from kernel.org.
You seem to have removed all the optimised i386 rwsem stuff... Did it not work
for you?
As said the design of
Andrea,
As said the design of the framework to plugin per-arch rwsem implementation
isn't flexible enough and the generic spinlocks are as well broken, try to
use them if you can (yes I tried that for the alpha, it was just a mess and
it was more productive to rewrite than to fix).
On Tue, Apr 17, 2001 at 08:18:57PM +0100, D . W . Howells wrote:
Andrea,
As said the design of the framework to plugin per-arch rwsem implementation
isn't flexible enough and the generic spinlocks are as well broken, try to
use them if you can (yes I tried that for the alpha, it was
Hi Andrea,
In article [EMAIL PROTECTED] you wrote:
I didn't exported rwsem.c if CONFIG_RWSEM_GENERIC is set to n as suggested
by Christoph yet because the old code couldn't be buggy and it's not obvious to
me that the other way around is correct (Christoph are you sure we can export an
I am sure ppc couldn't race (at least unless up_read/up_write were excuted
from irq/softnet context and that never happens in 2.4.4pre3, see below ;).
This is not actually using the rwsem code I wrote at the moment.
And incidentally the above is what (I guess Richard) did on the alpha and
On Tue, Apr 17, 2001 at 11:29:23PM +0200, Christoph Hellwig wrote:
Yes! All the objects in export-objs only get additional depencies in
Rules.make - but if they do not get compiled at all that depencies won't
matter either. All other makefile work this way, btw.
ok thanks for the confirm.
On Tue, Apr 17, 2001 at 10:48:02PM +0100, D . W . Howells wrote:
I disagree... you want such primitives to be as efficient as possible. The
whole point of having asm/.h files is that you can stuff them full of
dirty tricks specific to certain architectures.
Of course you always have the
It is 36bytes. and on 64bit archs the difference is going to be less.
You're right - I can't add up (must be too late at night), and I was looking
at wait_queue not wait_queue_head. I suppose that means my implementations
are then 20 and 16 bytes respectively.
On 64-bit archs the difference
66 matches
Mail list logo
