From: Daniel Phillips <phillips@nl.linux.org>
To: phillips@nl.linux.org, riel@conectiva.com.br
Cc: adilger@turbolinux.com, ext2-devel@lists.sourceforge.net,
jaharkes@cs.cmu.edu, linux-kernel@vger.kernel.org
Subject: Re: Ext2 Directory Index - Delete Performance
Date: Thu, 19 Apr 2001 12:55:28 +0200 [thread overview]
Message-ID: <20010419105540Z92314-11602+5@humbolt.nl.linux.org> (raw)
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
next reply other threads:[~2001-04-19 10:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-19 10:55 Daniel Phillips [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-04-19 11:44 Daniel Phillips
2001-04-19 10:42 Daniel Phillips
2001-04-19 1:22 Daniel Phillips
2001-04-19 3:02 ` Rik van Riel
2001-04-19 3:18 ` Alexander Viro
2001-04-19 0:27 Daniel Phillips
2001-04-19 1:11 ` Jan Harkes
2001-04-19 2:45 ` Rik van Riel
2001-04-19 3:23 ` Alexander Viro
2001-04-19 3:35 ` Rik van Riel
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=20010419105540Z92314-11602+5@humbolt.nl.linux.org \
--to=phillips@nl.linux.org \
--cc=adilger@turbolinux.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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
all inboxes | Powered by JetHome®