On Wed, Apr 12, 2006 at 02:28:35PM -0700, Mingming Cao wrote: > On Tue, 2006-04-11 at 15:20 -0700, Ravikiran G Thirumalai wrote: > > On Tue, Apr 11, 2006 at 12:01:13PM -0700, Mingming Cao wrote: > > > On Tue, 2006-04-11 at 10:09 -0700, Christoph Lameter wrote: > > > where the check for unsigned long overflow is only turned on 32 bit > platforms. > > > Or make the counter s64? so that it stays 64 bit on all arches? > > > > Well, don't we have the problem : 64 bit counter add/dec/update is not > always atomic on all 32 bit platforms? There are risk that we will get > bogus global value. Yes, but the global counter is modified with a lock in the SMP case, and the local counters are modified by their respective cpus only, Although there might be more subtle issues ..... > > > OR > > why not change the global per-cpu counter type to unsigned long (as we > > discussed earlier), so we don't need the extra "ul" flags and interfaces, > > and all arches get a standard unsigned long return type? > > We could also > > do away with percpu_read_positive then no? The applications for per-cpu > > counters is going to be upcounters always methinks... > > > > yeah...I am not so happy with the extra "ul" checking flags either. But > as you have mentioned before, the signed global counter type is there > for some cases when the global counter becomes temporally negative > ( although the counter in real life should always positive). What should > we do if the global counter is a unsigned value, was initialized to 0, > and now we add -5 to it(-5 is from one local counter, then we will get a > bogus big value)? I thought the solution to this was to have a global unsigned counter, and signed local counter, and defer updates to the global if it is going to be a large value due to the case above. This way the global counter remains an up counter no? Thanks, Kiran - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
