Messages in this thread | | | Date | Mon, 09 Sep 2002 14:44:35 -0700 | From | Andrew Morton <> | Subject | Re: LMbench2.0 results |
| |
Alan Cox wrote: > > On Sun, 2002-09-08 at 19:40, Andrew Morton wrote: > > We need to find some way of making vm_enough_memory not call get_page_state > > so often. One way of doing that might be to make get_page_state dump > > its latest result into a global copy, and make vm_enough_memory() > > only get_page_state once per N invokations. A speed/accuracy tradeoff there. > > Unless the error always falls on the same side the accuracy tradeoff is > fatal to the entire scheme of things. Sorting out the use of > get_page_state is worth doing if that is the bottleneck, and > snapshooting such that we only look at it if we might be close to the > limit would work, but we'd need to know when the limit had shifted too > much
It could be that the cost is only present on the IBM whackomatics, so they can twiddle the /proc setting and we can all be happy. Certainly I did not see any problems on the quad.
Does "heuristic" overcommit handling need so much accuracy? Perhaps we can push some of the cost over into mode 2 somehow.
Or we could turn it the other way up and, in __add_to_page_cache(), do:
if (overcommit_mode == anal) atomic_inc(&nr_pagecache_pages); - 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/
| |