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
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 corrupt anything. Its unlikely to and
> I do agree they two are lik
Well, here's the list of modules I have loaded:
nfsd 102496 8 (autoclean)
lockd 72976 1 (autoclean) [nfsd]
sunrpc 87984 1 (autoclean) [nfsd lockd]
nls_iso8859-1 4160 1 (autoclean)
nls_cp437 5664 1 (autoclean)
msdo
Peter Rival [[EMAIL PROTECTED]] wrote:
> Hmpf. Haven't seen this at all on any of the Alphas that I'm running. What
> exact system are you seeing this on, and what are you running when it happens?
This is a LX164 system, 533 MHz.
I have a hunch it's related to the X server because I've seen it
Hmpf. Haven't seen this at all on any of the Alphas that I'm running. What
exact system are you seeing this on, and what are you running when it happens?
- Pete
Bob McElrath wrote:
> Peter Rival [[EMAIL PROTECTED]] wrote:
> > You wouldn't happen to have khttpd loaded as a module, would you?
Peter Rival [[EMAIL PROTECTED]] wrote:
> You wouldn't happen to have khttpd loaded as a module, would you? I've seen
> this type of problem caused by that before...
Nope...
>
> - Pete
>
> Bob McElrath wrote:
>
> > I've been experiencing a particular kind of hang for many versions
> > (since
You wouldn't happen to have khttpd loaded as a module, would you? I've seen
this type of problem caused by that before...
- Pete
Bob McElrath wrote:
> I've been experiencing a particular kind of hang for many versions
> (since 2.3.99 days, recently seen with 2.4.1, 2.4.2, and 2.4.2-ac4) on
>
I've been experiencing a particular kind of hang for many versions
(since 2.3.99 days, recently seen with 2.4.1, 2.4.2, and 2.4.2-ac4) on
the alpha architecture. The symptom is that any program that tries to
access the process table will hang. (ps, w, top) The hang will go away
by itself after ~1
40 matches
Mail list logo
