On Fri, 2011-04-29 at 00:35 +0800, Eric Dumazet wrote:
> Le jeudi 28 avril 2011 Ã 11:17 -0500, Christoph Lameter a Ãcrit :
> > On Thu, 28 Apr 2011, Eric Dumazet wrote:
> >
> > > > If _sum() notices seqcount was changed too much, restart the loop.
> >
> > This does not address the issue of cpus adding batch -1 while the
> > loop is going on.
>
>
> Yes, it does, I left the needed changes to write side as an exercice ;)
>
>
> For example, based on current linux-2.6 code
>
>
> void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch)
> {
> s64 count;
>
> preempt_disable();
> count = __this_cpu_read(*fbc->counters) + amount;
> if (count >= batch || count <= -batch) {
> spin_lock(&fbc->lock);
> fbc->seqcount++;
> fbc->count += count;
> __this_cpu_write(*fbc->counters, 0);
> spin_unlock(&fbc->lock);
> } else {
> __this_cpu_write(*fbc->counters, count);
> }
> preempt_enable();
> }
yep, this can resolve Tejun's concern. The problem is how do you
determine maxfuzzy. This can mislead user too. Because in the worst
case, the deviation is num_cpu*batch. If a user uses a small maxfuzzy
and expect the max deviation is maxfuzzy, he actually will get a bigger
deviation in worst case.
Thanks,
Shaohua
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>