linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: zwu.kernel@gmail.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxram@linux.vnet.ibm.com, viro@zeniv.linux.org.uk,
	cmm@us.ibm.com, tytso@mit.edu,
	Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Subject: Re: [RFC v1 00/11] vfs: hot data tracking
Date: Tue, 18 Sep 2012 07:30:09 +1000	[thread overview]
Message-ID: <20120917213009.GH13691@dastard> (raw)
In-Reply-To: <1347866325-25979-1-git-send-email-zwu.kernel@gmail.com>

On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.kernel@gmail.com wrote:
> From: Zhi Yong Wu <wuzhy@linux.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@fromorbit.com

  parent reply	other threads:[~2012-09-17 21:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17  7:18 [RFC v1 00/11] vfs: hot data tracking zwu.kernel
2012-09-17  7:18 ` [RFC v1 01/11] vfs: introduce one structure hot_info zwu.kernel
2012-09-17  7:18 ` [RFC v1 02/11] vfs: introduce one rb tree - hot_inode_tree zwu.kernel
2012-09-17  7:18 ` [RFC v1 03/11] vfs: introduce 2 rb tree items - inode and range zwu.kernel
2012-09-17  7:18 ` [RFC v1 04/11] vfs: add support for updating access frequency zwu.kernel
2012-09-17  7:18 ` [RFC v1 05/11] vfs: add one new mount option '-o hottrack' zwu.kernel
2012-09-17  7:18 ` [RFC v1 06/11] vfs: add init and exit support zwu.kernel
2012-09-17  7:18 ` [RFC v1 07/11] vfs: introduce one hash table zwu.kernel
2012-09-17  7:18 ` [RFC v1 08/11] vfs: enable hot data tracking zwu.kernel
2012-09-17  7:18 ` [RFC v1 09/11] vfs: fork one private kthread to update temperature info zwu.kernel
2012-09-17  7:18 ` [RFC v1 10/11] vfs: add 3 new ioctl interfaces zwu.kernel
2012-09-17  7:18 ` [RFC v1 11/11] vfs: add debugfs support zwu.kernel
2012-09-17  9:45 ` [RFC v1 00/11] vfs: hot data tracking Marco Stornelli
2012-09-17 13:24   ` Zhi Yong Wu
2012-09-17 21:30 ` Dave Chinner [this message]
2012-09-18  2:24   ` Zhi Yong Wu
2012-09-18  6:20     ` Dave Chinner
2012-09-18  6:44       ` Zhi Yong Wu

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=20120917213009.GH13691@dastard \
    --to=david@fromorbit.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@linux.vnet.ibm.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wuzhy@linux.vnet.ibm.com \
    --cc=zwu.kernel@gmail.com \
    /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).