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
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 18
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
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 s
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
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 cl
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
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 _not
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 icac
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 times)
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 b
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, than
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 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 implementation
> 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
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 t
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 a
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, it
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).
Ha
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 o
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
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 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
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/peop
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 privile
33 matches
Mail list logo
