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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
