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@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>