linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* inode/dentry pressure
@ 2001-05-16 22:59 Rik van Riel
  2001-05-16 23:34 ` Alexander Viro
  2001-05-16 23:36 ` Jeff Garzik
  0 siblings, 2 replies; 4+ messages in thread
From: Rik van Riel @ 2001-05-16 22:59 UTC (permalink / raw)
  To: Ben LaHaise; +Cc: linux-mm, Alexander Viro, Ingo Molnar

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: inode/dentry pressure
  2001-05-16 22:59 inode/dentry pressure Rik van Riel
@ 2001-05-16 23:34 ` Alexander Viro
  2001-05-17  3:26   ` Ed Tomlinson
  2001-05-16 23:36 ` Jeff Garzik
  1 sibling, 1 reply; 4+ messages in thread
From: Alexander Viro @ 2001-05-16 23:34 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Ben LaHaise, linux-mm, Ingo Molnar


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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: inode/dentry pressure
  2001-05-16 22:59 inode/dentry pressure Rik van Riel
  2001-05-16 23:34 ` Alexander Viro
@ 2001-05-16 23:36 ` Jeff Garzik
  1 sibling, 0 replies; 4+ messages in thread
From: Jeff Garzik @ 2001-05-16 23:36 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Ben LaHaise, linux-mm, Alexander Viro, Ingo Molnar

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: inode/dentry pressure
  2001-05-16 23:34 ` Alexander Viro
@ 2001-05-17  3:26   ` Ed Tomlinson
  0 siblings, 0 replies; 4+ messages in thread
From: Ed Tomlinson @ 2001-05-17  3:26 UTC (permalink / raw)
  To: Alexander Viro, Rik van Riel; +Cc: linux-mm

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-05-17  3:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-16 22:59 inode/dentry pressure Rik van Riel
2001-05-16 23:34 ` Alexander Viro
2001-05-17  3:26   ` Ed Tomlinson
2001-05-16 23:36 ` Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox