Messages in this thread | | | Date | Fri, 10 Dec 2004 17:37:00 -0600 | From | Robin Holt <> | Subject | Re: [RFC] Limit the size of the IPV4 route hash. |
| |
On Fri, Dec 10, 2004 at 03:38:48PM -0800, Andrew Morton wrote: > Robin Holt <holt@sgi.com> wrote: > > > > > The big risk is that someone has a too-small table for some specific > > > application and their machine runs more slowly than it should, but they > > > never notice. I wonder if it would be possible to put a little once-only > > > printk into the routing code: "warning route-cache chain exceeded 100 > > > entries: consider using the rhash_entries boot option". > > > > Since the hash gets flushed every 10 seconds, what if we kept track of > > the maximum depth reached and when we reach a certain threshold, just > > allocate a larger hash and replace the old with the new. I do like the > > printk idea so the admin can prevent inconsistent performance early in > > the run cycle for the system. We could even scale the hash size up based > > upon demand. > > Once the system has been running for a while, the possibility of allocating > a decent number of physically-contiguous pages is basically zero. > > If we were to dynamically size it we'd need to either use new data > structure (slower) or use vmalloc() (slower and can fragment vmalloc > space).
Why do they need to be physically contiguous? It is a hash correct? - 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/
| |