From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@digeo.com>,
William Lee Irwin III <wli@holomorphy.com>,
Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
linux-kernel@vger.kernel.org
Subject: Re: LMbench2.0 results
Date: Sun, 08 Sep 2002 11:11:26 -0700 [thread overview]
Message-ID: <232327228.1031483485@[10.10.2.3]> (raw)
In-Reply-To: <1031504848.26888.238.camel@irongate.swansea.linux.org.uk>
>> >> 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)
next prev parent reply other threads:[~2002-09-08 18:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-07 12:18 LMbench2.0 results Paolo Ciarrocchi
2002-09-07 12:27 ` Jeff Garzik
2002-09-07 18:53 ` Rik van Riel
2002-09-07 21:44 ` Alan Cox
2002-09-13 22:46 ` Pavel Machek
2002-09-07 14:33 ` James Morris
2002-09-09 22:22 ` Cliff White
2002-09-07 16:20 ` Andrew Morton
2002-09-07 20:03 ` William Lee Irwin III
2002-09-07 23:12 ` Andrew Morton
2002-09-07 23:01 ` William Lee Irwin III
2002-09-07 23:44 ` Martin J. Bligh
2002-09-08 17:07 ` Alan Cox
2002-09-08 18:11 ` Martin J. Bligh [this message]
2002-09-08 18:40 ` Andrew Morton
2002-09-08 20:48 ` Hugh Dickins
2002-09-08 21:51 ` Andrew Morton
2002-09-09 21:13 ` Alan Cox
2002-09-09 21:44 ` Andrew Morton
2002-09-09 22:09 ` Alan Cox
2002-09-08 7:51 ` Andrew Morton
2002-09-08 7:37 ` David S. Miller
2002-09-08 8:28 ` William Lee Irwin III
2002-09-08 8:25 ` David S. Miller
2002-09-08 9:12 ` William Lee Irwin III
2002-09-08 20:02 ` Daniel Phillips
2002-09-09 13:37 ` Rik van Riel
2002-09-09 16:16 ` Daniel Phillips
2002-09-09 16:26 ` Martin J. Bligh
2002-09-09 16:55 ` Daniel Phillips
2002-09-09 17:24 ` Martin J. Bligh
2002-09-09 21:11 ` Alan Cox
2002-09-09 16:52 ` Andrew Morton
2002-09-07 12:40 Paolo Ciarrocchi
2002-09-07 14:09 Shane Shrybman
2002-09-07 18:04 Paolo Ciarrocchi
2002-09-13 22:49 ` Pavel Machek
2002-09-07 18:09 Paolo Ciarrocchi
2002-09-08 7:51 ` Andrew Morton
2002-09-14 18:26 Paolo Ciarrocchi
2002-09-15 18:08 ` Pavel Machek
2002-09-22 12:42 Paolo Ciarrocchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='232327228.1031483485@[10.10.2.3]' \
--to=martin.bligh@us.ibm.com \
--cc=akpm@digeo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ciarrocchi@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).