On Thu, Apr 13, 2006 at 03:25:39PM -0700, Mingming Cao wrote: > On Thu, 2006-04-13 at 12:02 -0700, Ravikiran G Thirumalai wrote: > > ... > > 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 ..... > > > Hmm, I was worried about the read to the 64 bit global counter, there is > no lock to protect it from getting an half updated 64 bit counter. But I > think the window is probably small, and with what Andreas suggested > (keep the local per cpu counter as 32 bit value), we would avoid this > non-atomic math in most cases. > > Well,anyway this counter is just an approximate value, and currently > (with 32 bit global counter) we could still read an old global counter > value while it's being updated since no lock is required while read it. Yup, and percpu_counter_exceeds should take care of the race in global counter reads where it matters. > > > > 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? > > > > I think that will work, and we could get rid of the cheating > percpu_counter_read_positive() totally;) > > So I think we could combine these two together: make the global counter > an unsigned 64 bit (u64) and keep the per cpu counter still signed 32 > bit type, and also, defer updates the global counter to the global if > the end result is larger that before. This way we could have remove the > need for percpu_counter_read_positive(), and also allow the counter > being used for 64 bit accounting on 32 bit arch. > > Comments? Sounds OK to me. 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
