[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120917213009.GH13691@dastard>
Date: Tue, 18 Sep 2012 07:30:09 +1000
From: Dave Chinner <david@...morbit.com>
To: zwu.kernel@...il.com
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxram@...ux.vnet.ibm.com, viro@...iv.linux.org.uk,
cmm@...ibm.com, tytso@....edu,
Zhi Yong Wu <wuzhy@...ux.vnet.ibm.com>
Subject: Re: [RFC v1 00/11] vfs: hot data tracking
On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.kernel@...il.com wrote:
> From: Zhi Yong Wu <wuzhy@...ux.vnet.ibm.com>
>
> NOTE:
>
> The patchset is currently post out mainly to make sure
> it is going in the correct direction and hope to get some
> helpful comments from other guys.
>
> TODO List:
>
> 1.) Need to do scalability or performance tests.
> 2.) Turn some Micro into tunables
> TIME_TO_KICK, and HEAT_UPDATE_DELAY
> 3.) Rafactor hot_hash_is_aging()
> If you just made the timeout value a timespec and compared
> the _timespecs_, you would be doing a lot fewer conversions.
> 4.) Cleanup some unnecessary lock protect
> 5.) Add more comments to explain how to calc temperature
0) Documentation.
> Zhi Yong Wu (11):
> vfs: introduce one structure hot_info
> vfs: introduce one rb tree - hot_inode_tree
> vfs: introduce 2 rb tree items - inode and range
These three patches can probably just be flattened into one.
Splitting out the first two doesn't add to the clarity of the
series - add the structures in the patch that actually uses them
so we don't ahve to jump between patches to see how they are used.
> vfs: add support for updating access frequency
> vfs: add one new mount option '-o hottrack'
> vfs: add init and exit support
> vfs: introduce one hash table
> vfs: enable hot data tracking
> vfs: fork one private kthread to update temperature info
> vfs: add 3 new ioctl interfaces
> vfs: add debugfs support
>
> fs/Makefile | 3 +-
> fs/compat_ioctl.c | 8 +
> fs/dcache.c | 2 +
> fs/direct-io.c | 10 +
> fs/hot_debugfs.c | 487 ++++++++++++++++++++++++++++++++++
> fs/hot_debugfs.h | 60 +++++
> fs/hot_hash.c | 369 ++++++++++++++++++++++++++
> fs/hot_hash.h | 108 ++++++++
> fs/hot_rb.c | 648 +++++++++++++++++++++++++++++++++++++++++++++
> fs/hot_rb.h | 70 +++++
> fs/hot_track.c | 113 ++++++++
> fs/hot_track.h | 23 ++
> fs/ioctl.c | 132 +++++++++
> fs/namespace.c | 10 +
> fs/super.c | 11 +
> include/linux/fs.h | 15 +
> include/linux/hot_track.h | 169 ++++++++++++
> mm/filemap.c | 8 +
> mm/page-writeback.c | 21 ++
> mm/readahead.c | 9 +
> 20 files changed, 2275 insertions(+), 1 deletions(-)
> create mode 100644 fs/hot_debugfs.c
> create mode 100644 fs/hot_debugfs.h
> create mode 100644 fs/hot_hash.c
> create mode 100644 fs/hot_hash.h
> create mode 100644 fs/hot_rb.c
> create mode 100644 fs/hot_rb.h
> create mode 100644 fs/hot_track.c
> create mode 100644 fs/hot_track.h
> create mode 100644 include/linux/hot_track.h
So, 9 new files for tracking all of this? I'm not sure that so
many new files are needed - putting it all in fs/hot_tracking.[ch]
might make more sense, or if all 8 fs/hot* files remain, putting
them in their own subdirectory might be an idea (like quota).
I'll comment on the code when I get a bit of time to look at it.
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists