On Wed, 6 Oct 2010 11:44:31 +0200, Jan Kara <jack@xxxxxxx> wrote:
> On Wed 06-10-10 11:08:00, Dmitry wrote:
> > On Tue, 5 Oct 2010 22:20:16 +0400, Dmitry Monakhov <dmonakhov@xxxxxxxxxx> wrote:
> > Sorry, seems like my script screw-up subject header.
> > > This patch set is my first attempt to make quota code scalable.
> > > Main goal of this patch-set is to split global locking to per-sb basis.
> > > Please review it and provide your opinion.
> > >
> > > Future plans:
> > > * More scalability for single super_block
> > > ** Remove dqptr_sem
> > > ** Redesing dquot ref accounting interface.
> > > ** Make fast path for charge function lockless
> > >
BTW i've forgot to mention that patch-set against 2.6.36-rc5
linux-fs-2.6.git for_testing branch
> > > quota: add wrapper function
> > > quota: Convert dq_state_lock to per-sb dq_state_lock
> > > quota: add quota format lock
> > > quota: make dquot lists per-sb
> > > quota: make per-sb hash array
> > > quota: remove global dq_list_lock
> > > quota: rename dq_lock
> > > quota: make per-sb dq_data_lock
> > > quota: protect dquot mem info with objects's lock
> > > quota: drop dq_data_lock where possible
> > > quota: relax dq_data_lock dq_lock locking consistency
> So one generic question: I see you split global locks into per-sb ones.
> Does it bring substantial advantage? Because from my experience common
> systems have just one or maybe two filesystems which are heavily used...
It was so in the past, but currently hardware is too powerful for single
system. Today is the age of virtual environments (containers, cgroups,
etc). Usually each VE has it own filesystem. And people do care about
density, and scalability. So we need scalable quota for each VE.
In fact this patch-set was inspired by Nick's attempt to remove
global inode_lock.
I've skip serious performance testing for that version, i just
want to hear opinions about the way i'm moving.
I can post some numbers for next patch-set version.
>
> Honza
> --
> Jan Kara <jack@xxxxxxx>
> SUSE Labs, CR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
