All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: vm-kswapd-incmin.patch problem
       [not found] <20051122074818.GA3801@mail.ustc.edu.cn>
@ 2005-11-23  4:06 ` Wu Fengguang
  2005-11-23  8:01   ` Nick Piggin
  0 siblings, 1 reply; 2+ messages in thread
From: Wu Fengguang @ 2005-11-23  4:06 UTC (permalink / raw)
  To: Nick Piggin; +Cc: linux-kernel

Hi Nick,

On Tue, Nov 22, 2005 at 03:48:18PM +0800, Wu Fengguang wrote:
> Hi, your vm-kswapd-incmin.patch looks nice, and I'd like to base my age
> balancing patch upon it. But while trying it, I ran into a problem.
> 
> $ cp bigfile /dev/null
> $ free -m    
>              total       used       free     shared    buffers     cached
> Mem:           501        495          6          0          2        321
> -/+ buffers/cache:        171        330
> Swap:          127          2        125
> $ sleep 10
> $ free -m    
>              total       used       free     shared    buffers     cached
> Mem:           501        244        257          0          4         66
> -/+ buffers/cache:        173        328
> Swap:          127          2        125
> 
> In a short time, the bigfile was totally evicted from page cache?
> 
> Before/after the huge free pages:
> 
> $ cat /proc/sys/fs/dentry-state
> 3393    28      45      0       0       0
> $ cat /proc/sys/fs/dentry-state
> 3626    260     45      0       0       0
> 
> 
> linux-2.6.15-rc1-mm2 without the patch seems ok.
> Any suggestions? Thanks.

Maybe I found the answer to it :)

I listed the dentry-state in several other normal machines, they all have
more than 10k unused dentries:

        54215   42155   45      0       0       0
        91704   81376   45      0       0       0
        96304   88832   45      0       0       0
        30057   26999   45      0       0       0

Then I disabled the shrinker by:
        echo 0 > /proc/sys/vm/vfs_cache_pressure

That increased the number from
        3393    28      45      0       0       0
to
        6247    2672    45      0       0       0
And there is no sudden huge increases of free pages any more.

Maybe your patch is shrinking the slabs much more, though I cannot confirm this
from the source code. But one thing I'm sure is that there should be a lower
bound for the unused dentries, either absolutely or relatively, something like
this:

--- linux-2.6.15-rc1-mm2.orig/fs/dcache.c
+++ linux-2.6.15-rc1-mm2/fs/dcache.c
@@ -860,7 +860,7 @@ static int shrink_dcache_memory(int nr, 
 			return -1;
 		prune_dcache(nr);
 	}
-	return (dentry_stat.nr_unused / 100) * sysctl_vfs_cache_pressure;
+	return (dentry_stat.nr_unused / 1000) * 10 * sysctl_vfs_cache_pressure;
 }
 
 /**


The original 100 is way too small. It should be much more than the SHRINK_BATCH(128).

Thanks,
Wu

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

* Re: vm-kswapd-incmin.patch problem
  2005-11-23  4:06 ` vm-kswapd-incmin.patch problem Wu Fengguang
@ 2005-11-23  8:01   ` Nick Piggin
  0 siblings, 0 replies; 2+ messages in thread
From: Nick Piggin @ 2005-11-23  8:01 UTC (permalink / raw)
  To: Wu Fengguang; +Cc: linux-kernel

Wu Fengguang wrote:
> Hi Nick,
> 

Hi Wu,

> Then I disabled the shrinker by:
>         echo 0 > /proc/sys/vm/vfs_cache_pressure
> 
> That increased the number from
>         3393    28      45      0       0       0
> to
>         6247    2672    45      0       0       0
> And there is no sudden huge increases of free pages any more.
> 

Yes, the inode shrinker can discard all pagecache from a file if
it is under a lot of pressure to free inodes. This is what you
are seeing I guess.

> Maybe your patch is shrinking the slabs much more, though I cannot confirm this
> from the source code. But one thing I'm sure is that there should be a lower
> bound for the unused dentries, either absolutely or relatively, something like
> this:
> 
> --- linux-2.6.15-rc1-mm2.orig/fs/dcache.c
> +++ linux-2.6.15-rc1-mm2/fs/dcache.c
> @@ -860,7 +860,7 @@ static int shrink_dcache_memory(int nr, 
>  			return -1;
>  		prune_dcache(nr);
>  	}
> -	return (dentry_stat.nr_unused / 100) * sysctl_vfs_cache_pressure;
> +	return (dentry_stat.nr_unused / 1000) * 10 * sysctl_vfs_cache_pressure;
>  }
>  

I don't think that kswapd-incmin puts much more pressure on the slab
(unless there is a bug), but I'll take a look. It could just be a
"weird" interaction in the reclaim code, or possibly a rounding issue.

Changing the pressure calculation here is probably not the right way
to do this, but rather in vmscan.c. I know Andrea has recently been
looking at a problem with slab shrinking too.

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

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

end of thread, other threads:[~2005-11-23  8:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20051122074818.GA3801@mail.ustc.edu.cn>
2005-11-23  4:06 ` vm-kswapd-incmin.patch problem Wu Fengguang
2005-11-23  8:01   ` Nick Piggin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.