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);
...
}
-
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 : Sun Sep 15 2002 - 22:00:33 EST