inode/dentry pressure

inode/dentry pressure

[Rik van Riel]

Hi,

since the inode and dentry cache memory usage and the way this
memory is reaped by kswapd are still very fragile and these
caches often eat as much as 50% of system memory on normal
desktop systems I think we need to come up with a real solution
to this problem.

A quick fix would be to always try and reap inode and dentry
cache memory whenever these two eat over 10% of memory and let
the normal VM path eat from them when they're consuming less,
but since this could break in other situations I'm asking here
if anybody else has a real solution...

If we cannot find an easy to implement Real Solution(tm) we
should probably go for the 10% limit in 2.4 and implement the
real solution in 2.5; if anybody has a 2.4-attainable idea
I'd like to hear about it ;)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: inode/dentry pressure

[Alexander Viro]

On Wed, 16 May 2001, Rik van Riel wrote:

> If we cannot find an easy to implement Real Solution(tm) we
> should probably go for the 10% limit in 2.4 and implement the
> real solution in 2.5; if anybody has a 2.4-attainable idea
> I'd like to hear about it ;)

Rip the crap from icache hard, fast and often. _Any_ inode with
no dentry is fair game as soon as it's clean. Keep in mind
that icache is a secondary cache - we are talking about the
stuff dcache didn't want to keep.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: inode/dentry pressure

[Ed Tomlinson]

On Wednesday 16 May 2001 19:34, Alexander Viro wrote:
> On Wed, 16 May 2001, Rik van Riel wrote:
> > If we cannot find an easy to implement Real Solution(tm) we
> > should probably go for the 10% limit in 2.4 and implement the
> > real solution in 2.5; if anybody has a 2.4-attainable idea
> > I'd like to hear about it ;)
>
> Rip the crap from icache hard, fast and often. _Any_ inode with
> no dentry is fair game as soon as it's clean. Keep in mind
> that icache is a secondary cache - we are talking about the
> stuff dcache didn't want to keep.

I have been running with this patch for the last few weeks.  It 
adds a call to kswapd that prunes dead dentries quickly.  Think it
qualifies as something that does "Rip the crap from icache hard, 
fast and often". 

Comments?

Ed Tomlinson

--- 2.4.4-pre7/include/linux/dcache.h	Thu Apr 26 12:57:47 2001
+++ linux/include/linux/dcache.h	Fri Apr 27 18:17:20 2001
@@ -176,6 +176,7 @@

 /* icache memory management (defined in linux/fs/inode.c) */
 extern void shrink_icache_memory(int, int);
+extern void shrink_unused_icache_memory(int);
 extern void prune_icache(int);

 /* only used at mount-time */
--- 2.4.4-pre7/mm/vmscan.c	Fri Apr 27 11:36:04 2001
+++ linux/mm/vmscan.c	Fri Apr 27 18:33:07 2001
@@ -953,6 +953,11 @@
 		 */
 		refill_inactive_scan(DEF_PRIORITY, 0);

+		/*
+		 * Free unused inodes.
+		 */
+		shrink_unused_icache_memory(GFP_KSWAPD);
+
 		/* Once a second, recalculate some VM stats. */
 		if (time_after(jiffies, recalc + HZ)) {
 			recalc = jiffies;
--- 2.4.4-pre7/fs/inode.c	Thu Apr 26 12:49:33 2001
+++ linux/fs/inode.c	Fri Apr 27 18:54:25 2001
@@ -540,16 +540,16 @@
 	 !inode_has_buffers(inode))
 #define INODE(entry)	(list_entry(entry, struct inode, i_list))

-void prune_icache(int goal)
+/*
+ * Called with inode lock held, returns with it released.
+ */
+int prune_unused_icachei_unlock(int goal)
 {
 	LIST_HEAD(list);
 	struct list_head *entry, *freeable = &list;
-	int count = 0, synced = 0;
+	int count = 0;
 	struct inode * inode;

-	spin_lock(&inode_lock);
-
-free_unused:
 	entry = inode_unused.prev;
 	while (entry != &inode_unused)
 	{
@@ -577,19 +577,27 @@

 	dispose_list(freeable);

+	return count;
+}
+
+/*
+ * A goal of zero frees everything
+ */
+void prune_icache(int goal)
+{
+	spin_lock(&inode_lock);
+	goal -= prune_unused_icachei_unlock(goal);
+
 	/*
 	 * If we freed enough clean inodes, avoid writing
-	 * dirty ones. Also giveup if we already tried to
-	 * sync dirty inodes.
+	 * dirty ones.
 	 */
-	if (!goal || synced)
+	if (!goal)
 		return;

-	synced = 1;
-
 	spin_lock(&inode_lock);
 	try_to_sync_unused_inodes();
-	goto free_unused;
+ 	prune_unused_icache_unlock(goal);
 }

 void shrink_icache_memory(int priority, int gfp_mask)
@@ -611,6 +619,20 @@

 	prune_icache(count);
 	kmem_cache_shrink(inode_cachep);
+}
+
+void shrink_unused_icache_memory(int gfp_mask)
+{
+	/*
+	 * Nasty deadlock avoidance..
+	 */
+	if (!(gfp_mask & __GFP_IO))
+		return;
+
+	if (spin_trylock(&inode_lock)) {
+		prune_unused_icache_unlock(0);
+		kmem_cache_shrink(inode_cachep);
+	}
 }

 /*

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: inode/dentry pressure

[Jeff Garzik]

Rik van Riel wrote:
> since the inode and dentry cache memory usage and the way this
> memory is reaped by kswapd are still very fragile and these
> caches often eat as much as 50% of system memory on normal
> desktop systems I think we need to come up with a real solution
> to this problem.
> 
> A quick fix would be to always try and reap inode and dentry
> cache memory whenever these two eat over 10% of memory and let
> the normal VM path eat from them when they're consuming less,
> but since this could break in other situations I'm asking here
> if anybody else has a real solution...
> 
> If we cannot find an easy to implement Real Solution(tm) we
> should probably go for the 10% limit in 2.4 and implement the
> real solution in 2.5; if anybody has a 2.4-attainable idea
> I'd like to hear about it ;)

IMHO this is more of a policy question, though I agree strongly it needs
some sort of answer.

When applications start competing with disposable OS caches, of all
sorts, you have to decide cache reap rate, and a suitable low water mark
for each cache in order for the system to be useable under heavy load. 
Some caches are going to have a higher low-water mark than others; some
caches may need to be reaped more slowly due to various issues.

-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/