Messages in this thread Patch in this message |  | | Date | Sun, 08 Sep 2002 11:11:26 -0700 | From | "Martin J. Bligh" <> | Subject | Re: LMbench2.0 results |
| |
>> >> Perhaps testing with overcommit on would be useful. >> > >> > Well yes - the new overcommit code was a significant hit on the 16ways >> > was it not? You have some numbers on that? >> >> About 20% hit on system time for kernel compiles. > > That suprises me a lot. On a 2 way and 4 way the 2.4 memory overcommit > check code didnt show up. That may be down to the 2 way being on a CPU > that has no measurable cost for locked operations and the 4 way being an > ancient ppro a friend has.
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/
|  |