All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 6/6] ext4: Dynamically allocate the jbd2_inode in ext4_inode_info as necessary
Date: Tue, 11 Jan 2011 16:50:43 -0500	[thread overview]
Message-ID: <20110111215043.GG2917@thunk.org> (raw)
In-Reply-To: <A562E0CA-9CA6-4654-8FCB-9849F6EB09E7@dilger.ca>

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

      parent reply	other threads:[~2011-01-11 21:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05  1:01 [PATCH 0/6] Shrinking the size of ext4_inode_info Theodore Ts'o
2011-01-05  1:01 ` [PATCH 1/6] ext4: replace i_delalloc_reserved_flag with EXT4_STATE_DELALLOC_RESERVED Theodore Ts'o
2011-01-05  1:01 ` [PATCH 2/6] ext4: Use ext4_lblk_t instead of sector_t for logical blocks Theodore Ts'o
2011-01-05  1:01 ` [PATCH 3/6] ext4: Drop ec_type from the ext4_ext_cache structure Theodore Ts'o
2011-01-05  1:01 ` [PATCH 4/6] ext4: reorder ext4_inode_info structure elements to remove unneeded padding Theodore Ts'o
2011-01-05  1:01 ` [PATCH 5/6] ext4: Drop i_state_flags on architectures with 64-bit longs Theodore Ts'o
2011-01-05 18:43   ` Andreas Dilger
2011-01-05 20:29     ` Ted Ts'o
2011-01-06  7:23       ` Andreas Dilger
2011-01-06 17:55         ` Ted Ts'o
2011-01-06 21:15           ` [PATCH] " Theodore Ts'o
2011-01-05  1:01 ` [PATCH 6/6] ext4: Dynamically allocate the jbd2_inode in ext4_inode_info as necessary Theodore Ts'o
2011-01-05  9:26   ` Amir Goldstein
2011-01-05 20:21     ` Ted Ts'o
2011-01-05 19:26   ` Andreas Dilger
2011-01-05 20:21     ` Ted Ts'o
2011-01-06 22:14     ` Ted Ts'o
2011-01-07  2:36       ` [PATCH -v2] " Theodore Ts'o
2011-01-07 20:46         ` Amir Goldstein
2011-01-07 22:40           ` Ted Ts'o
2011-01-11 21:50     ` Ted Ts'o [this message]

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=20110111215043.GG2917@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.