Messages in this thread | | | Date | Tue, 13 Jul 2004 08:17:15 -0500 | From | "Jose R. Santos" <> | Subject | Re: [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/
| |