On Saturday 29 July 2006 19:38, Michal Mertl wrote: > Paul Allen wrote: > > Surely all you need to do is a cheap crit_enter,crit_exit > > while updating the 64-bit per cpu counters. and on > > a 64-bit arch you skip the crit_enter,crit_exit. > > Critical_enter/exit seem to be quite lightweight (single > read/modify/write of a variable). > > > Seriously this is a bike shed. We can summarize it thus: > > statistics should be maintained in 64-bit counters, these > > counters should be per-cpu and consistent in that context, > > nothing else should appear on the critical path. > > Why do you call it a bikesched? I think that your proposal could work > but as nobody proposed doing the stuff with critical_* before, the > thread may be fruitful. > > Is critical_* good enough protection though? What if two threads were > updating the same per-CPU counter on the same CPU at the same time? With > 64bits counter on a 32bit architecture? I expect the cache coherency > issues are completely eliminated with per-CPU data, aren't they? critical_* would prevent an interrupt from preempting the thread, so you wouldn't have this case. That said, I think just using a simple algo (like inc; jnc 1b; inc; 1:) would be fine. With the counter being per-cpu you don't even need the 'lock' prefix for i386. You would have to find similar solutions for other 32-bit archs (arm, ppc, mips). -- John BaldwinReceived on Mon Jul 31 2006 - 16:02:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC