* Re: 2.1.110 freepages.min change
[not found] <Pine.LNX.3.96.980722181024.13036A-100000@mirkwood.dummy.home>
@ 1998-07-22 20:27 ` Dr. Werner Fink
1998-07-23 14:43 ` Stephen C. Tweedie
0 siblings, 1 reply; 2+ messages in thread
From: Dr. Werner Fink @ 1998-07-22 20:27 UTC (permalink / raw
To: Linux Kernel; +Cc: linux-mm
On Wed, Jul 22, 1998 at 06:12:37PM +0200, Rik van Riel wrote:
> Hi Linus,
>
> I've noticed that, in 2.1.110, the value for the
> minimum amount of free pages changed from 48 to
> 10.
>
> Considering the amount of fragmentation problems
> observed and the numbers generated by your fragmentation
> calculation program, this seems a tad on the low side...
>
> If fragmentation problems show up, I suggest we up this
> limit again...
>
It seem's that if the limit is reached now the new try_to_free_pages
instead of the old try_to_free_page(without s) function may free some
more pages as requested ... in best case SWAP_CLUSTER_MAX pages are
freed at once ... looks good Linus. Together with the increased
count_max and count_min in shrink_mmap this one really makes sense.
The change in fs/dcache.c does not look very well because
as higher the number given to prune_dache in shrink_dcache_memory
as more the dcache is pruned ... `0' isn't that good is it?
Werner
PS: I've updated my lowmem.patch to 2.1.110. I would like to
hear some comments on it ... for more please see
http://www.suse.de/~werner/patches/
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: 2.1.110 freepages.min change
1998-07-22 20:27 ` 2.1.110 freepages.min change Dr. Werner Fink
@ 1998-07-23 14:43 ` Stephen C. Tweedie
0 siblings, 0 replies; 2+ messages in thread
From: Stephen C. Tweedie @ 1998-07-23 14:43 UTC (permalink / raw
To: Dr. Werner Fink; +Cc: Linux Kernel, linux-mm
On Wed, 22 Jul 1998 22:27:36 +0200, "Dr. Werner Fink" <werner@suse.de> said:
> The change in fs/dcache.c does not look very well because
> as higher the number given to prune_dache in shrink_dcache_memory
> as more the dcache is pruned ... `0' isn't that good is it?
Werner, have you given it a shot? With this fix in place, the
dcache/inode fragmentation issues in 2.1 are very dramatically improved
on low memory. I'm very pleased indeed with this patch: even if it's
only prune_dcache(0), it is still being called much more often when we
get short of memory.
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1998-07-23 17:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.3.96.980722181024.13036A-100000@mirkwood.dummy.home>
1998-07-22 20:27 ` 2.1.110 freepages.min change Dr. Werner Fink
1998-07-23 14:43 ` Stephen C. Tweedie
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.