lkml.org 
[lkml]   [2002]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:28    [W:0.025 / U:0.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site