lkml.org 
[lkml]   [2004]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Making i/dhash_entries cmdline work as it use to.
On 07/13/04 05:29:13, David Howells wrote:
>
> Jose R. Santos <jrsantos@austin.ibm.com> wrote:
> > Also, any particular reason why MAX_SYS_HASH_TABLE_ORDER was set to 14?
> > I am already seeing the need to go higher on my 64GB setup and was
> > wondering if this could be bumped up to 19.
>
> Yes. IBM did some testing and found that was about optimal. No significant
> gain was found with anything greater.

On a single setup. What about people that want to use Linux on a 128way with
over a terabyte of memory. Certainly ORDER 14 might be to small for them.

> > I'm sending a patch that get the cmdline options working as the did before
> > where the could override the kernel calculations and increases
> > MAX_SYS_HASH_TABLE_ORDER to 19. Only tested on PPC64 at the moment.
>
> You need to be careful increasing the maximum order - you have to remember
> that this affects several tables (well, at least two at the moment), and so
> the effect is multiplied.

Only if I use the cmdline option. With no command line arguments this allocate
the kernels sain calculated defaults.

> It may be reasonable to let the kernel cmdline override the maximum number of
> buckets calculated on the scaling factor provided to the function (effectively
> number of buckets per unit memory), but consider that the number of objects
> that can be allocated and linked into the table is in effect governed by such
> a factor.

It seems easier to specify a the number of buckets you want than specifying a
scaling factor, which some people may have problems figuring out.

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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.057 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site