On Fri, 11 Jun 2010 16:29:59 -0700
Tim Chen <tim.c.chen@linux.intel.com> wrote:
Sure, that's inevitable if we want to avoid one-atomic-op-per-operation.
The comparisons with 0 and 1 are ugly (although not necessarily wrong).
The code would be nicer if we replace free_blocks with used_blocks and
perform comparisons agains max_blocks.
Yup. We're assuming here that we can tolerate overshooting max_blocks a bit.
percpu_counters have a precise limit too! It's
percpu_counter_batch*num_online_cpus. You can implement your own
tolerance by not using percpu_counter_batch: pass your own batch into
__percpu_counter_add().
There's a trick that can be done to improve accuracy. When checking to
see if the fs is full, use percpu_counter_read(). If the number that
percpu_counter_read() returns is "close" to max_blocks, then start
using the more expensive percpu_counter_sum(). So the kernel will be
fast, until the disk gets to within (batch*num_online_cpus) blocks of
being full.
This is not the first time I've seen that requirement, and it would be
a good idea to implement the concept within an addition to the
percpu_counter library. Say, percpu_counter_compare().
percpu_counter_compare(struct percpu_counter *fbc, s64 rhs) would
compare percpu_counter_read() with `rhs' and if they're within
num_online_cpus*percpu_counter_batch, call percpu_counter_sum().
__percpu_counter_compare() would take the additional `batch' argument.
I think. Needs a bit of head-scratching, because callers don't really
care about num_online_cpus. The caller only really cares about the
absolute error.
(Where the heck did the "fbc" name come from? I forget...)
--
