public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Bill Davenport" <dragonpt@rcn.com>
To: <linux-kernel@vger.kernel.org>
Subject: Can prune_icache safely discard inodes which have only clean pages? (2.4.18)
Date: Fri, 13 Sep 2002 07:49:53 -0400	[thread overview]
Message-ID: <005a01c25b1b$ac7fb390$3083accf@tabasco> (raw)

I've got a system which has a fairly large amount of physical memory (2GB)
that experiences
performance problems after a large number of files have been accessed.

Looking into the slab_info I discovered that a very large number of inodes
are currently
present in the system (along with many buffer headers). Digging deeper I was
able to determine
that most of the inodes were on the inode_unused chain, but were being
skipped over during
the prunce_icache processing because they have a non-zero number of pages
(i_data.nrpages).
Looking a bit deeper I discovered that most of the inodes had only pages
that are on the
clean_pages list, with these pages also accounting for many of the buffer
heads.

The system wasn't attempting to free these pages (presumably since it still
had a fair
amount of physical memory available, so it didn't need to do this).

Is there any danger in changing prune_icache to also pick an inode for
pruning if it has
a non-zero page count where the dirty_list and locked_list are empty?

In particular, the existing code in fs/inode.c looks somewhat like:

 #define CAN_UNUSE(inode) \
  ((((inode)->i_state | (inode)->i_data.nrpages) == 0)  && \
   !inode_has_buffers(inode))
 void prune_icache(int goal)
 {
  ...
  while (entry != &inode_unused)
  {
   ...
   if (inode->i_state & (I_FREEING|I_CLEAR|I_LOCK))
    continue;
   if (!CAN_UNUSE(inode))
    continue;

   Remove inode from i_hash and add to freeable
  }
  ...
  dispose_list(freeable);
  ...
 }

and I'd like to change it to:

 void prune_icache(int goal)
 {
  ...
  while (entry != &inode_unused)
  {
   ...
   if (inode->i_state & (I_FREEING|I_CLEAR|I_LOCK))
    continue;
   if ((inode->i_state != 0) || inode_has_buffers(inode))
    continue;
   if (inode->i_data.nrpages != 0) {
    if ((!list_empty(&inode->i_data.dirty_pages)) ||
        (!list_empty(&inode->i_data.locked_pages))) {
     /* skip if any dirty or locked pages */
     continue;
    }
   }

   Remove inode from i_hash and add to freeable
  }
  ...
  dispose_list(freeable);
  ...
 }



             reply	other threads:[~2002-09-13 11:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-13 11:49 Bill Davenport [this message]
2002-09-13 19:57 ` Can prune_icache safely discard inodes which have only clean pages? (2.4.18) Andrew Morton

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='005a01c25b1b$ac7fb390$3083accf@tabasco' \
    --to=dragonpt@rcn.com \
    --cc=linux-kernel@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