Re: Ext2 Directory Index - Delete Performance

From: Daniel Phillips (phillips@nl.linux.org)
Date: Thu Apr 19 2001 - 05:55:28 EST


Rik van Riel wrote:
> On Thu, 19 Apr 2001, Daniel Phillips wrote:
> > Jan Harkes wrote:
> > > On Thu, Apr 19, 2001 at 02:27:48AM +0200, Daniel Phillips wrote:
> > > > more memory. If you have enough memory, the inode cache won't thrash,
> > > > and even when it does, it does so gracefully - performance falls off
> > > > nice and slowly. For example, 250 Meg of inode cache will handle 2
> > > > million inodes with no thrashing at all.
> > >
> > > What inode cache are you talking about? According to the slabinfo output
> > > on my machine every inode takes up 480 bytes in the inode_cache slab. So
> > > 250MB is only able to hold about half a million inodes in memory.
> >
> > Sorry, I was a little loose with terminology there. I should have
> > said "inode blocks in cache". The inode cache is related. When an
> > Ext2 inode is pushed out of the inode cache it gets transfered to a
> > dirty block in memory, where it shrinks to 128 bytes and shares the
> > block with 31 other inodes. These blocks are in the buffer cache, and
> > this is the cache I'm talking about.
>
> Hmmm, considering this, it may be wise to limit the amount of
> inodes in the inode cache to, say, 10% of RAM ... because we
> can cache MORE inodes if we store them in the buffer cache
> instead!

Yes, one struct inode is worth 3.5 buffer cache inodes. The expense of
converting the inode via read_inode and update_inode is pretty small. To
come up with a balancing formula, we should consider:

  - Ratio between struct inode size and inode disk image size
  - CPU cost of converting an inode disk image to struct inode
  - CPU cost of converting a struct inode to a disk image
  - average time to read, write a block of N inodes.
  - Load on memory
  - Bandwidth of disk, heaviness of disk traffic
  - Other factors I forgot

Or we could just set the inode cache size lower and see what happens. :-)

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:30 EST