Re: [RFC v1 00/11] vfs: hot data tracking

[Dave Chinner]

On Tue, Sep 18, 2012 at 10:24:55AM +0800, Zhi Yong Wu wrote:
> On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.kernel@xxxxxxxxx wrote:
> >>  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.

A single file is much easier to handle when searching and editting,
though. And realistically:

$ wc -l fs/*.c |sort -nr -k 1 |head -10
  62483 total
   4000 fs/namei.c
   3281 fs/buffer.c
   3169 fs/dcache.c
   2677 fs/namespace.c
   2364 fs/locks.c
   2321 fs/exec.c
   2120 fs/binfmt_elf.c
   2053 fs/splice.c
   1934 fs/eventpoll.c
$

There are plenty of files for a single function/subsystem of around
the aggregate size of this code, so everyone is used to dealing with
this amount of logic for a particular feature in a single file.

I much prefer it that way, to tell the truth, because I find it
fairly common to have 5-10 files open at once when tracking
something through, say, the buffered IO path. If I've now got to
have another 5-10 files open just to track that same code path
through this index, then that makes it much more difficult to
manage than if were all in one .c file.

IOWs, splitting code up into multiple files is not a win when the
resultant files are all small and interdependent and you need to
look at multiple files at the same time to understand what the code
does as a whole....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/