Hello, Dave. On Thu, Oct 08, 2015 at 12:02:18PM +1100, Dave Chinner wrote: > > percpu cmpxchg is no different from sub or any other operations > > regarding cross-CPU synchronization. They're safe iff the operations > > are on the local CPU. They have to be made atomics if they need to be > > manipulated from remote CPUs. > > Again, another trivially solvable problem, but still irrelevant > because we don't have the data that tells us whether changing the > counter behaviour solves the problem.... Dude, it isn't trivially solvable. You either can't do it or have to pay the overhead during local access to get around it. > > That said, while we can't manipulate the percpu counters directly, we > > can add a separate global counter to cache sum result from the > > previous run which gets automatically invalidated when any percpu > > counter overflows. > > > > That should give better and in case of > > back-to-back invocations pretty good precision compared to just > > returning the global overflow counter. Interface-wise, that'd be a > > lot easier to deal with although I have no idea whether it'd fit this > > particular use case or whether this use case even exists. > > No, it doesn't help - it's effectively what Waiman's original patch > did by returning the count from the initial comparison and using > that for ENOSPC detection instead of doing a second comparison... Just chipping in purely from percpu side. If what Waiman suggested is something useable, caching the result inside percpu_counter would be a better interface. If not, no idea. Thanks. -- tejun _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
