linux-ext4.vger.kernel.org archive mirror
 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: Wed, 5 Jan 2011 15:21:03 -0500	[thread overview]
Message-ID: <20110105202103.GM2959@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).  There will now be two
> allocations for every inode, and the extra packing these allocations
> into slabs will increase memory usage for an inode, and would
> definitely result in more allocation/freeing overhead.
> 
> The main question is how many files are ever opened for write?

Even if we do two allocations for every inode (not just inodes opened
for write), it's a win simply because moving the jinode out the
ext4_inode_info structure shrinks it sufficiently that we can now pack
18 inodes in a 16k slab on x86_64.  It turns out that the slab
allocator is pretty inefficient at large data structures, and smaller
data structures (such as the jbd2_inode structure) it handles much
more efficiently, in terms of wasted memory.

> 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).

Sure.  It should be possible to release jinfo when the file is
completely closed, in ext4_release_file.  That would reduce the memory
footprint significantly.  I hadn't bothered with it too badly because
the jbd2_inode structure is only 48 bytes, and you can fit 85 of them
on a 4k page with only 16 bytes getting wasted.  But it's fair that we
release jinode once the inode is no longer used by any file descriptors.


I'll make the the other changes you suggested; thanks!!

							- Ted

  reply	other threads:[~2011-01-05 20:21 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 [this message]
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     ` [PATCH 6/6] " Ted Ts'o

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=20110105202103.GM2959@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).