From: Zhi Yong Wu <zwu.kernel@gmail.com>
To: Dave Chinner <david@fromorbit.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 10:24:55 +0800 [thread overview]
Message-ID: <CAEH94LgfxDa2=TubEFcDAyPD=UPfa2yJ-y0Rn7Dto6zs90xScw@mail.gmail.com> (raw)
In-Reply-To: <20120917213009.GH13691@dastard>
On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner <david@fromorbit.com> wrote:
> 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.
It make sense to me, OK, thanks.
>
>> 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).
If all functions are in two files, they will be large and the logic is
not so clear. so i prefer the latter. thanks.
>
> I'll comment on the code when I get a bit of time to look at it.
Great, very look forward to your more comments.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
--
Regards,
Zhi Yong Wu
next prev parent reply other threads:[~2012-09-18 2:24 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
2012-09-18 2:24 ` Zhi Yong Wu [this message]
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='CAEH94LgfxDa2=TubEFcDAyPD=UPfa2yJ-y0Rn7Dto6zs90xScw@mail.gmail.com' \
--to=zwu.kernel@gmail.com \
--cc=cmm@us.ibm.com \
--cc=david@fromorbit.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 \
/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).