Re: [PATCH] shrink hash sizes on small machines, take 2

[Gerald Schaefer]

On Tuesday 18 May 2004 19:42, you wrote:
> num_physpages should represent the memory available to the kernel for
> normal use and should not reflect any other reserved memory. Otherwise
> it'll unduly influence the hash sizes both with and without this
> patch.
This is a very good point, Arnd and I have been looking at our "mem=" hack
and it does look a little bit fishy...
There are possibly more things affected in the s390 kernel with "mem="
parameter, not only num_physpages (max_low_pfn, etc.), so we will have to
take a closer look and see what Martin thinks about it.

> Index: mm/fs/dcache.c
> ===================================================================
> --- mm.orig/fs/dcache.c       2004-05-18 12:29:28.000000000 -0500
> +++ mm/fs/dcache.c    2004-05-18 12:37:42.000000000 -0500
> @@ -1625,7 +1625,7 @@
>       /* Base hash sizes on available memory, with a reserve equal to
>             150% of current kernel size */
>  
> -     reserve = (mempages - nr_free_pages()) * 3/2;
> +     reserve = min((mempages - nr_free_pages()) * 3/2, mempages - 1);
>       mempages -= reserve;
>  
>       names_cachep = kmem_cache_create("names_cache",
This patch is o.k. for us, in our case (with "mem=") it would more or less
restore the previous situation (without the calculation, but still with a
potential memory problem on our side)

--
Gerald
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/