From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, davej@redhat.com,
viro@zeniv.linux.org.uk, jack@suse.cz, glommer@parallels.com
Subject: Re: [PATCH 02/11] inode: add IOP_NOTHASHED to avoid inode hash lock in evict
Date: Thu, 1 Aug 2013 01:12:35 -0700 [thread overview]
Message-ID: <20130801081235.GA7261@infradead.org> (raw)
In-Reply-To: <1375244150-27296-3-git-send-email-david@fromorbit.com>
On Wed, Jul 31, 2013 at 02:15:41PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Some filesystems don't use the VFS inode hash and fake the fact they
> are hashed so that all the writeback code works correctly. However,
> this means the evict() path still tries to remove the inode from the
> hash, meaning that the inode_hash_lock() needs to be taken
> unnecessarily. Hence under certain workloads the inode_hash_lock can
> be contended even if the inode is never actually hashed.
>
> To avoid this, add an inode opflag to allow inode_hash_remove() to
> avoid taking the hash lock on inodes have never actually been
> hashed.
Good idea, but I don't like how it's implemented.
First a formality: i_opflags really is for flags showing that inode
operations exist, not for addional bits. Just use i_flags for it.
Second this is a hack hacking around a hack. We just mark the inode
hashed so that writeback doesn't ignore it, and not we need to work
around the fact that we don't want an inode marked hashed from the
hashlist.
As the most simple version I'd suggest to just add an I_NEEDS_WRITEBACK
flag which gets set by __insert_inode_hash, and all the current users
of hlist_add_fake on i_hash, as well as the block devices that currently
have another special case in the writeback code.
Thinking about it I'm not even sure I_NEEDS_WRITEBACK is needed, no
that we have I_NEW as a marker a negative test for it should be
enough, but doing this might require some further research.
next prev parent reply other threads:[~2013-08-01 8:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 4:15 [PATCH 00/11] Sync and VFS scalability improvements Dave Chinner
2013-07-31 4:15 ` [PATCH 01/11] writeback: plug writeback at a high level Dave Chinner
2013-07-31 14:40 ` Jan Kara
2013-08-01 5:48 ` Dave Chinner
2013-08-01 8:34 ` Jan Kara
2013-07-31 4:15 ` [PATCH 02/11] inode: add IOP_NOTHASHED to avoid inode hash lock in evict Dave Chinner
2013-07-31 14:44 ` Jan Kara
2013-08-01 8:12 ` Christoph Hellwig [this message]
2013-08-02 1:11 ` Dave Chinner
2013-08-02 14:32 ` Christoph Hellwig
2013-07-31 4:15 ` [PATCH 03/11] inode: convert inode_sb_list_lock to per-sb Dave Chinner
2013-07-31 14:48 ` Jan Kara
2013-07-31 4:15 ` [PATCH 04/11] sync: serialise per-superblock sync operations Dave Chinner
2013-07-31 15:12 ` Jan Kara
2013-07-31 4:15 ` [PATCH 05/11] inode: rename i_wb_list to i_io_list Dave Chinner
2013-07-31 14:51 ` Jan Kara
2013-07-31 4:15 ` [PATCH 06/11] bdi: add a new writeback list for sync Dave Chinner
2013-07-31 15:11 ` Jan Kara
2013-08-01 5:59 ` Dave Chinner
2013-07-31 4:15 ` [PATCH 07/11] writeback: periodically trim the writeback list Dave Chinner
2013-07-31 15:15 ` Jan Kara
2013-08-01 6:16 ` Dave Chinner
2013-08-01 9:03 ` Jan Kara
2013-07-31 4:15 ` [PATCH 08/11] inode: convert per-sb inode list to a list_lru Dave Chinner
2013-08-01 8:19 ` Christoph Hellwig
2013-08-02 1:06 ` Dave Chinner
2013-07-31 4:15 ` [PATCH 09/11] fs: Use RCU lookups for inode cache Dave Chinner
2013-07-31 4:15 ` [PATCH 10/11] list_lru: don't need node lock in list_lru_count_node Dave Chinner
2013-07-31 4:15 ` [PATCH 11/11] list_lru: don't lock during add/del if unnecessary Dave Chinner
2013-07-31 6:48 ` [PATCH 00/11] Sync and VFS scalability improvements Sedat Dilek
2013-08-01 6:19 ` Dave Chinner
2013-08-01 6:31 ` Sedat Dilek
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=20130801081235.GA7261@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=david@fromorbit.com \
--cc=glommer@parallels.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).