[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-smp
Subject:    Re: Locks
From:       Russell Leighton <russ () taylor ! digex ! net>
Date:       1998-03-31 18:00:33
[Download RAW message or body]

Nice work, thanks to all involved.

Robert G. Brown wrote:
> 
> On Tue, 31 Mar 1998, Alan Cox wrote:
> 
> > Yuck yuck I hope not. SMP should be generating
> >
> >       lock btsl $1, 26(%eax)
> 
> I defined __SMP__ and now yes, the set_bit translates into:
> 
> #APP
>         lock ; btsl $1,26(%eax)
>         sbbl %eax,%eax
> #NO_APP
> 
> (Still don't know what the #APP/#NO_APP does.  Does anyone?)
> 
> I've just tested a set_bit hacked, __SMP__ tulip.c.  Rock solid.  No
> more "Too much work" messages, no aieee's, even when subjecting a dual
> PPro to two simultaneous PII streams totalling roughly 80Kpps (something
> that was instant death before, and caused an occassional aieee even with
> set_bit but no __SMP__ defined).  I suppose it will need even more
> testing, but I'm optimistic now that this is indeed it.
> 
> If anybody else is interested, I'll post a tulip.c patch (which is
> fairly simple) but I'm going to send this back to Don Becker -- he's
> added a bunch of debugging code to the network drivers to deal with this
> and will probably want to strip it back out in the development version.
> I think that I can come up with the eepro100 patch too.  I don't have
> anything else to test, but I think that the idea is straightforward now
> and fixing the fast ethernet drivers will be easy.
> 
> THANKS, Alan, for the help:-)
> 
>      rgb
> 
> Robert G. Brown                        http://www.phy.duke.edu/~rgb/
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu


-- 
-----------------------------------------------------------
Russell Leighton    russ@radyn.com    russ@taylor.digex.net
-----------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]