linux-ext4 - Re: [PATCH 6/6] ext4: Dynamically allocate the jbd2_inode in ext4_inode

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: <20110111215043.GG2917@thunk.org>
Date:	Tue, 11 Jan 2011 16:50:43 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger.kernel@...ger.ca>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 6/6] ext4: Dynamically allocate the jbd2_inode in
 ext4_inode_info as necessary

On Wed, Jan 05, 2011 at 12:26:33PM -0700, Andreas Dilger wrote:
> 
> How does this change impact the majority of users that are running
> with a journal?  It is clearly a win for a small percentage of users
> with no-journal mode, but it may be a net increase in memory usage
> for the majority of the users (with journal)....
> 
> The main question is how many files are ever opened for write?  It
> isn't just the number of currently-open files for write, because the
> jinfo isn't released until the inode is cleared from memory.  While
> I suspect that most inodes in cache are never opened for write, it
> would be worthwhile to compare the ext4_inode_cache object count
> against the jbd2_inode object count, and see how the total memory
> compares to a before-patch system running different workloads (with
> journal).

So here's one unscientific data point, based on your humble kernel
developer who happens to read e-mail using mutt and a Maildir
directory (which has lots of read-only files, one per e-mail) and does
primarily source code editing, kernel builds, web browsing, e-mail,
and irc/IM:

Slabcache: ext4_inode_cache      Aliases:  0 Order :  3 Objects: 70820
Slabcache: jbd2_inode            Aliases:  5 Order :  0 Objects: 22126

Note that jbd2_inode is aliased, so not all 22,126 objects are
necessarily jbd2_inodes.  Some of them might also be ip_fib_alias,
ksm_mm_slot, anon_vma_chain, Acpi-Parse, and nsproxy objects.  But
still, the ratio of inodes that I've ever written to inodes that have
only been accessed read-only is over 3:1.

So for at least my laptop/desktop workload, using a separate
jbd2_inode structure is clearly a win, and in fact separating out more
of the ext4_inode_cache structure to create a separate data structure
for fieldsonly needed when the file is opened for writing would likely
be a win.  I can probably peel off another 100 bytes or so from the
ext4_inode_info data structure.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html