Remember this is a NUMA machine - gathering global information
is extremely expensive. On an SMP system, I wouldn't expect it
to show up so much, though it still doesn't seem terribly efficient.
The code is admits it's broken anyway, for the overcommit = 2 case
(which was NOT what I was running - the 20% is for 1). Below is a
simple patch that I've never got around to testing, that I think
will improve that case (not that I'm that interested in setting
overcommit to 2 ;-)).
> If it is the memory overcommit handling then there are plenty of ways to
> deal with it efficiently in the non-preempt case at least. I had
> wondered originally about booking chunks of pages off per CPU (take the
> remaining overcommit divide by four and only when a CPU finds its
> private block is empty take a lock and redistribute the remaining
> allocation). Since boxes almost never get that close to overcommit
> kicking in then it should mean we close to never touch a locked count.
Can you use per-zone stats rather than global ones? That tends to
fix things pretty efficently on these type of machines - per zone
LRUs made a huge impact.
Here's a little patch (untested!). I'll go look at the other case
and see if there's something easy to do, but I think it needs some
significant rework to do anything.
--- virgin-2.5.30.full/mm/mmap.c Thu Aug 1 14:16:05 2002
+++ linux-2.5.30-vm_enough_memory/mm/mmap.c Wed Aug 7 13:26:46 2002
@@ -74,7 +74,6 @@
int vm_enough_memory(long pages)
{
unsigned long free, allowed;
- struct sysinfo i;
atomic_add(pages, &vm_committed_space);
@@ -115,12 +114,7 @@
return 0;
}
- /*
- * FIXME: need to add arch hooks to get the bits we need
- * without this higher overhead crap
- */
- si_meminfo(&i);
- allowed = i.totalram * sysctl_overcommit_ratio / 100;
+ allowed = totalram_pages * sysctl_overcommit_ratio / 100;
allowed += total_swap_pages;
if (atomic_read(&vm_committed_space) < allowed)
-
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/