[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Possible dcache BUG
    On Wednesday 11 August 2004 21:26, Nick Piggin wrote:
    >Gene Heskett wrote:
    >>On Wednesday 11 August 2004 01:15, Linus Torvalds wrote:
    >>>On Tue, 10 Aug 2004, Linus Torvalds wrote:
    >>>>So I suspect it's a balancing issue. Possibly just the slight
    >>>>change in slab balancing to fix the highmem problems. Maybe we
    >>>>shrink slab _too_ aggressively or something.
    >>>Udo, that's a simple thing to check. If it's the slab balancing
    >>>changes, then you should be able to test it with just a
    >>> bk cset -x1.1830.4.3
    >>>if you have the current BK and are a BK user, or by just revertign
    >>>the patch here ("patch -R -p1" from inside your linux source tree)
    >>>if you're not a BK user..
    >>> Linus
    >>With the previously attached patch reverted, a fresh kernel builds
    >> in: real 7m18.296s
    >>user 5m49.385s
    >>sys 0m31.760s
    >>which is a marked improvement, but still about 1m30 or so slow.
    >This could easily be from too much slab pressure. How much memory do
    > you have?

    1 Gb in 2 512Mb sticks of DDR400 ram which signs on in the bios as
    dual channel. The sticks are in the first and third slots as
    recommended by the mobo docs.

    >Have you got highmem turned on?

    >The new slab pressure calculation is an improvement in that it won't
    > let slab
    >get out of control and cause OOMs, however it can shrink the slab
    > too much. If you regularly need ZONE_DMA pages, for example. AFAIKS
    > there isn't much you
    >can do about this except go to per-zone slab LRUs.

    And how would an otherwise clueless user like me determine that?

    >That said, your stability problems should be resolved first. If they
    > are fixed,

    Which as yet is an unknown, Nick. Uptime now at
    22:15:14 up 12:30, 5 users, load average: 1.03, 1.11, 1.05

    >and you would like to help track down the slowdown, run the kernel
    >compile about
    >3 times each with and without the patch, and save cat /proc/vmstat
    >before and
    >after each compile. Try to keep all else constant.

    I'll try that if I get to a 30+ hour uptime.


    Cheers, Gene
    "There are four boxes to be used in defense of liberty:
    soap, ballot, jury, and ammo. Please use in that order."
    -Ed Howdershelt (Author)
    99.24% setiathome rank, not too shabby for a WV hillbilly attorneys please note, additions to this message
    by Gene Heskett are:
    Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.026 / U:3.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site