On Sat, 2007-04-21 at 12:21 -0700, Andrew Morton wrote:
> On Sat, 21 Apr 2007 13:02:26 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > > > + cpu = get_cpu();
> > > > + pcount = per_cpu_ptr(fbc->counters, cpu);
> > > > + count = *pcount + amount;
> > > > + if (count >= FBC_BATCH || count <= -FBC_BATCH) {
> > > > + spin_lock(&fbc->lock);
> > > > + fbc->count += count;
> > > > + *pcount = 0;
> > > > + spin_unlock(&fbc->lock);
> > > > + } else {
> > > > + *pcount = count;
> > > > + }
> > > > + put_cpu();
> > > > +}
> > > > +EXPORT_SYMBOL(percpu_counter_mod64);
> > >
> > > Bloaty. Surely we won't be needing this on 32-bit kernels? Even monster
> > > PAE has only 64,000,000 pages and won't be using deltas of more than 4
> > > gigapages?
> > >
> > > <Does even 64-bit need to handle 4 gigapages in a single hit? /me
> > > suspects
> > > another changelog bug>
> >
> > Yeah, /me chastises himself for that...
> >
> > This is because percpu_counter is s64 instead of the native long; I need
> > to halve the counter at some point (bdi_writeout_norm) and do that by
> > subtracting half the current value.
>
> ah, the mysterious bdi_writeout_norm().
>
> I don't think it's possible to precisely halve a percpu_counter - there has
> to be some error involved. I guess that's acceptable within the
> inscrutable bdi_writeout_norm().
>
> otoh, there's a chance that the attempt to halve the counter will take the
> counter negative, due to races. Does the elusive bdi_writeout_norm()
> handle that? If not, it should. If it does, then there should be comments
> around the places where this is being handled, because it is subtle, and
> unobvious,
> and others might break it by accident.
The counter it is halving is only ever incremented, so we might be off a
little, but only to the safe side.
I shall do the comment thing along with all the other missing
comments :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
