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] [day] [month] [year] [list]

Message-ID: <CAEH94Ljz+KS9z+mmzTVp2DvPoLgLmtVD_Bv_KP61Ey5KobN=0Q@mail.gmail.com>
Date:	Tue, 18 Sep 2012 14:44:14 +0800
From:	Zhi Yong Wu <zwu.kernel@...il.com>
To:	Dave Chinner <david@...morbit.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 2:20 PM, Dave Chinner <david@...morbit.com> wrote:
> 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....
Just completed move them to one separate directory fs/hot_tracking/.
But what you said makes sense to me, OK, i will adopt your suggestion,
thanks.

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@...morbit.com



-- 
Regards,

Zhi Yong Wu
--
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/