From: npiggin@kernel.dk
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
npiggin@kernel.dk
Subject: [patch 00/14] reworked minimal inode_lock breaking series
Date: Fri, 22 Oct 2010 00:08:29 +1100 [thread overview]
Message-ID: <20101021130829.442910807@kernel.dk> (raw)
I am still very much against the locking design of Dave's patchset, but
especially the way it is broken out. I could fathom accepting some of the
i_lock width reduction if they are properly broken out and justified and
documented why they are safe. But lumping this huge series of stuff before
inode_lock is even lifted is not the right way to go about it.
I still maintain that i_lock for icache state lock is the way to go at least
until we get quite a way down the track. I think a lot of people can't see it
maybe because my patchset wasn't broken out terribly well.
So I am posting here just the initial lock breaking part, reworked. In
particular, i_lock coverage is established before adding broken out data
structure locks, but it also cleans things up and attempts not to move stuff
around that isn't strictly required.
I still wait until everything is covered before touching inode_lock, but I have
explained how it is actually possible to start removing some of inode_lock even
before then, which I think is a good demonstration of the power of having full
i_lock coverage.
The steps here should be relatively easy to follow and verify (I hope), and
they lead quite easily to the actual scalability improvement steps. So please
don't get sidetracked on the temporary trylock ugliness!
Thanks,
Nick
next reply other threads:[~2010-10-21 13:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 13:08 npiggin [this message]
2010-10-21 13:08 ` [patch 01/14] fs: icache begin inode_lock lock breaking npiggin
2010-10-21 13:08 ` [patch 02/14] fs: icache lock i_count npiggin
2010-10-21 13:08 ` [patch 03/14] fs: icache lock inodes icache state npiggin
2010-10-21 13:08 ` [patch 04/14] fs: icache unmount code cleanup npiggin
2010-10-21 13:08 ` [patch 05/14] fs: icache lock s_inodes list npiggin
2010-10-21 13:08 ` [patch 06/14] fs: icache lock inode hash npiggin
2010-10-21 13:08 ` [patch 07/14] fs: icache lock lru/writeback lists npiggin
2010-10-21 13:08 ` [patch 08/14] fs: icache make nr_inodes and nr_unused atomic npiggin
2010-10-21 13:08 ` [patch 09/14] fs: inode atomic last_ino, iunique lock npiggin
2010-10-21 13:08 ` [patch 10/14] fs: icache remove inode_lock npiggin
2010-10-21 13:08 ` [patch 11/14] fs: icache factor hash lock into functions npiggin
2010-10-21 13:08 ` [patch 12/14] fs: icache lazy inode lru npiggin
2010-10-21 13:08 ` [patch 13/14] fs: icache split IO and LRU lists npiggin
2010-10-21 15:28 ` Christoph Lameter
2010-10-22 0:00 ` Nick Piggin
2010-10-22 1:05 ` Nick Piggin
2010-10-21 13:08 ` [patch 14/14] fs: icache split writeback and lru locks npiggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101021130829.442910807@kernel.dk \
--to=npiggin@kernel.dk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).