search for: rcsc

...t 2. That did not in fact enlighten things. Are they transitive/multi-copy atomic or not? (and here Will will go into great detail on the differences between the two and make our collective brains explode :-) > >That is, currently all architectures -- with exception of PPC -- have > >RCsc locks, but using these non-transitive things will get you RCpc > >locks. > > > >So yes, MIPS can go RCpc for its locks and share the burden of pain with > >PPC, but that needs to be a very concious decision. > > I don't understand that - I tried hard but I can'...

...ync+addr test: P0: Wx = 1 P1: Rx == 1 SYNC Wy = 1 P2: Ry == 1 <address dep> Rx = 0 I can't find anything to forbid that, given the text. The main problem is having the SYNC on P1 affect the write by P0. > That is, currently all architectures -- with exception of PPC -- have > RCsc locks, but using these non-transitive things will get you RCpc > locks. > > So yes, MIPS can go RCpc for its locks and share the burden of pain with > PPC, but that needs to be a very concious decision. I think it's much worse than RCpc, given my interpretation of the wording. Wi...

...ync+addr test: P0: Wx = 1 P1: Rx == 1 SYNC Wy = 1 P2: Ry == 1 <address dep> Rx = 0 I can't find anything to forbid that, given the text. The main problem is having the SYNC on P1 affect the write by P0. > That is, currently all architectures -- with exception of PPC -- have > RCsc locks, but using these non-transitive things will get you RCpc > locks. > > So yes, MIPS can go RCpc for its locks and share the burden of pain with > PPC, but that needs to be a very concious decision. I think it's much worse than RCpc, given my interpretation of the wording. Wi...

...itive and therefore cannot be used to implement the > smp_mb__{before,after} stuff. > > That is, in MIPS speak, those SYNC types are Ordering Barriers, not > Completion Barriers. Please see above, point 2. > That is, currently all architectures -- with exception of PPC -- have > RCsc locks, but using these non-transitive things will get you RCpc > locks. > > So yes, MIPS can go RCpc for its locks and share the burden of pain with > PPC, but that needs to be a very concious decision. I don't understand that - I tried hard but I can't find any word like &quo...

...ow exactly they interact. And smp_load_acquire()/smp_store_release() are RCpc because TSO archs and PPC. the atomic*_{acquire,release}() are RCpc because PPC and LOCK,UNLOCK are similarly RCpc because of PPC. Now we'd like PPC to stick a SYNC in either LOCK or UNLOCK so at least the locks are RCsc again, but they resist for performance reasons but waver because they don't want to be the ones finding all the nasty bugs because they're the only one. Now the thing I worry about, and still have not had an answer to is if weakly ordered MIPS will end up being RCsc or RCpc for their locks...

...sitive separate for the time being anyway. Just because it > > might be possible to deal with does not necessarily mean that we should > > be encouraging it. ;-) > > So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would > not someone trying to implement RCsc locks using locally transitive > RELEASE/ACQUIRE operations need exactly this stuff? > > That is, I am afraid we need to cover the mix of local and global > transitive operations at least in overview. True, but we haven't gotten to locking yet. That said, I would argue that smp_m...

...sitive separate for the time being anyway. Just because it > > might be possible to deal with does not necessarily mean that we should > > be encouraging it. ;-) > > So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would > not someone trying to implement RCsc locks using locally transitive > RELEASE/ACQUIRE operations need exactly this stuff? > > That is, I am afraid we need to cover the mix of local and global > transitive operations at least in overview. True, but we haven't gotten to locking yet. That said, I would argue that smp_m...

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with >

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with >

...; And smp_load_acquire()/smp_store_release() are RCpc because TSO archs > and PPC. the atomic*_{acquire,release}() are RCpc because PPC and > LOCK,UNLOCK are similarly RCpc because of PPC. > > Now we'd like PPC to stick a SYNC in either LOCK or UNLOCK so at least > the locks are RCsc again, but they resist for performance reasons but > waver because they don't want to be the ones finding all the nasty bugs > because they're the only one. I believe that the relevant proverb said something about starving to death between two bales of hay... ;-) > Now the thing...

...; And smp_load_acquire()/smp_store_release() are RCpc because TSO archs > and PPC. the atomic*_{acquire,release}() are RCpc because PPC and > LOCK,UNLOCK are similarly RCpc because of PPC. > > Now we'd like PPC to stick a SYNC in either LOCK or UNLOCK so at least > the locks are RCsc again, but they resist for performance reasons but > waver because they don't want to be the ones finding all the nasty bugs > because they're the only one. I believe that the relevant proverb said something about starving to death between two bales of hay... ;-) > Now the thing...

On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two

On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two

On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > An the only point - please use an appropriate SYNC_* barriers instead of > heavy bold hammer. That stuff was design explicitly to support the > requirements of Documentation/memory-barriers.txt That's madness. That document changes from version to version as to what we _think_ the actual hardware does. It is _NOT_ a

On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > An the only point - please use an appropriate SYNC_* barriers instead of > heavy bold hammer. That stuff was design explicitly to support the > requirements of Documentation/memory-barriers.txt That's madness. That document changes from version to version as to what we _think_ the actual hardware does. It is _NOT_ a

...s. They need not be globally performed. Which if true; and I know Will has some questions here; would also mean that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was recently suggested by David Daney. That is, currently all architectures -- with exception of PPC -- have RCsc locks, but using these non-transitive things will get you RCpc locks. So yes, MIPS can go RCpc for its locks and share the burden of pain with PPC, but that needs to be a very concious decision.

...nsitive > and non-transitive separate for the time being anyway. Just because it > might be possible to deal with does not necessarily mean that we should > be encouraging it. ;-) So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would not someone trying to implement RCsc locks using locally transitive RELEASE/ACQUIRE operations need exactly this stuff? That is, I am afraid we need to cover the mix of local and global transitive operations at least in overview.

On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote: > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > > > >

On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote: > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > > > >

Can someone verify that I am having the same problem with Mac OS X Panther (10.3.3) using Samba 3.0.2 based on my log below? I get this trying to connect from my WinXP machine to my Mac which is configured with ADS. If so, can you point me to a set of instructions on upgrading from 3.0.2 to 3.0.4 with this patch? I don't have control over the server I authenticate with...it is about 300