Re: [PATCH] Making i/dhash_entries cmdline work as it use to.

[Jose R. Santos]

On 07/13/04 05:29:13, David Howells wrote:
> 
> Jose R. Santos <jrsantos@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/