Messages in this thread |  | | Subject | Re: LMbench2.0 results | From | Alan Cox <> | Date | 08 Sep 2002 18:07:28 +0100 |
| |
On Sun, 2002-09-08 at 00:44, Martin J. Bligh wrote: > >> 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.
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.
- 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/
|  |