Messages in this thread | | | Date | Mon, 5 Apr 2004 16:19:16 -0500 | From | Matt Mackall <> | Subject | Re: [PATCH] shrink core hashes on small systems |
| |
On Mon, Apr 05, 2004 at 02:02:23PM -0700, Andrew Morton wrote: > Matt Mackall <mpm@selenic.com> wrote: > > > > Shrink hashes on small systems > > > > Tweak vfs_caches_init logic so that hashes don't start growing as > > quickly on small systems. > > > > - vfs_caches_init(num_physpages); > > + /* Treat machines smaller than 6M as having 2M of memory > > + for hash-sizing purposes */ > > + vfs_caches_init(max(500, (int)num_physpages-1000)); > > This seems rather arbitrary. It also implicitly "knows" that > PAGE_SIZE=4096.
Yep. I can reword it in terms of pages, if that helps. Boxes with 8k pages tend to have larger instruction words and data structures by virtue of being RISC/64bit/etc., so I think 1000 pages is a reasonable number in either case.
> num_physpages is of course the wrong thing to use here - on small systems > we should be accounting for memory which is pinned by kernel text, etc. > > But you're going further than that. What's the theory here?
Basically, the numfreepages approach doesn't take into account the size of the kernel/critical userspace at all. So we assume that anything less than 4M is already tight and that we're not yet in a position to trade space for performance, so lets just pull that off the top.
Longer term, I think some serious thought needs to go into scaling hash sizes across the board, but this serves my purposes on the low-end without changing behaviour asymptotically.
-- Matt Mackall : http://www.selenic.com : Linux development and consulting - 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/
| |