tmpfs: Make tmpfs scalable with percpu_counter for used blocks
in [Kernel]
|
Prev: transhuge-memcg: some fixes (Re: Transparent Hugepage Support #25)
Next: [PATCH] ASoC: Fix overflow bug in SOC_DOUBLE_R_SX_TLV
From: Minchan Kim on 17 Jun 2010 21:40 Hello. The idea is good. :) On Fri, Jun 18, 2010 at 8:56 AM, Tim Chen <tim.c.chen(a)linux.intel.com> wrote: > The current implementation of tmpfs is not scalable. > We found that stat_lock is contended by multiple threads > when we need to get a new page, leading to useless spinning > inside this spin lock. > > This patch makes use of the percpu_counter library to maintain local > count of used blocks to speed up getting and returning > of pages. So the acquisition of stat_lock is unnecessary > for getting and returning blocks, improving the performance > of tmpfs on system with large number of cpus. On a 4 socket > 32 core NHM-EX system, we saw improvement of 270%. > Good enhancement. :) > Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com> > include/linux/shmem_fs.h | 3 ++- > mm/shmem.c | 40 +++++++++++++++++----------------------- > 2 files changed, 19 insertions(+), 24 deletions(-) > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > index e164291..399be5a 100644 > --- a/include/linux/shmem_fs.h > +++ b/include/linux/shmem_fs.h > @@ -3,6 +3,7 @@ > > #include <linux/swap.h> > #include <linux/mempolicy.h> > +#include <linux/percpu_counter.h> > > /* inode in-kernel data */ > > @@ -23,7 +24,7 @@ struct shmem_inode_info { > > struct shmem_sb_info { > unsigned long max_blocks; /* How many blocks are allowed */ > - unsigned long free_blocks; /* How many are left for allocation */ > + struct percpu_counter used_blocks; /* How many are allocated */ Just a nitpick. Why do you change free_blocks and used_blocks? I think we can use free_blocks following as. ex) if (percpu_counter_compare(&sbinfo->free_blocks, 0)) Do you have any reason? Please, justify it. Thanks, Tim. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |