Messages in this thread | | | Subject | Re: [PATCH v2 1/2] tmpfs: Quick token library to allow scalable retrieval of tokens from token jar | From | Tim Chen <> | Date | Fri, 11 Jun 2010 16:29:59 -0700 |
| |
On Fri, 2010-06-11 at 15:26 -0700, Andrew Morton wrote:
> } > @@ -422,11 +423,11 @@ static swp_entry_t *shmem_swp_alloc(stru > */ > if (sbinfo->max_blocks) { > spin_lock(&sbinfo->stat_lock); > - if (sbinfo->free_blocks <= 1) { > + if (percpu_counter_read(&sbinfo->free_blocks) <= 1) { > spin_unlock(&sbinfo->stat_lock);
Thanks for pointing me to look at this alternative implementation.
However, looking at the percpu counter code, it appears that the percpu_counter_read is imprecise. The counters in the per cpu counters are not accounted and the value read may be much less than the true amount of free blocks left when used in the patch above. We could fail the above test and not allocate pages when we actually have additional pages available. Using percpu_counter_sum will give the precise count but will cause the acquisition of the spin lock in the percpu_counter and slowed things down in this performance critical path. If we feel that we could tolerate fuzziness on the size we configured for tmpfs, then this could be the way to go.
However, qtoken library implementation will impose a precise limit and has the per cpu counter's speed advantage.
Tim
| |