Re: [PATCH] percpu: preemptless __per_cpu_counter_add

[Tejun Heo <tj@kernel.org>]

Hello, Hugh.

On Tue, Apr 26, 2011 at 12:02:15PM -0700, Hugh Dickins wrote:
> This worried me a little when the percpu block counting went into tmpfs,
> though it's not really critical there.
> 
> Would it be feasible, with these counters that are used against limits,
> to have an adaptive batching scheme such that the batches get smaller
> and smaller, down to 1 and to 0, as the total approaches the limit?
> (Of course a single global percpu_counter_batch won't do for this.)
> 
> Perhaps it's a demonstrable logical impossibility, perhaps it would
> slow down the fast (far from limit) path more than we can afford,
> perhaps I haven't read enough of this thread and I'm taking it
> off-topic.  Forgive me if so.

Hmmm... it seems like what you're suggesting is basically a simple
per-cpu slot allocator.

* The global counter is initialized with predefined number of slots
  and per-cpu buffers start at zero (or with initial chunks).

* Allocation first consults per-cpu buffer and if enough slots are
  there, they're consumed.  If not, global counter is accessed and
  some portion of it is transferred to per-cpu buffer and allocation
  is retried.  The amount transferred is adjusted according to the
  amount of slots available in the global pool.

* Free populates the per-cpu buffer.  If it meets certain criteria,
  part of the buffer is returned to the global pool.

The principles are easy but as with any per-cpu allocation scheme
balancing and reclaiming would be the complex part.  ie. What to do
when the global and some per-cpu buffers are draining while a few
still have some left.

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>