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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120918062020.GR11511@dastard>
Date:	Tue, 18 Sep 2012 16:20:20 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Zhi Yong Wu <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 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@...morbit.com> wrote:
> > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.kernel@...il.com 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@...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/