[lkml]   [2001]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectVM brokenness, possibly related to reiserfs
    (Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect

    Ok, having approached this slightly more intelligently here are [better]

    The dumps are large so they are located at Here's
    the story. I boot and startx, I load xmms and netscape to eat away
    memory. When free buffers/cache falls below 7M the system stalls and
    the only recovery is sysrq-E or reboot. At the moment of stall the disk
    will grind continuously for about 25 to 30 minutes then go silent. At
    this point in time the only recovery is reboot, sysrq-E won't work.

    If I move the mouse or type a key within 30 seconds of this incident,
    that user input will take about 5 minutes to register. After that
    initial minute, nothing more will happen.

    Kernel 2.4.1, with reiserfs, devfs, no patches applied.

    "klog-X" are basically the same thing but I'm running top, syslogd, and
    klogd with -20 priority. I didn't note anything out of the ordinary in
    top. These are snapshots where I've managed to murder processes and
    restart the problem without rebooting.

    In the second instance, I had my finger on the kill button and managed
    to kill netscape and recover partially. However the system was heavily
    loaded even after the kill.

    I have xmms in STOPped state so it's just waiting.

    kswapd is taking 12.2% of the CPU according to ps, and kapm-idled is
    taking 26.9%. bdflush is taking 2.7%, X 3.5%, all others are nominal.
    The system load was hovering at 1.00 for a few minutes then dropped to
    zero. However scrolling text in an rxvt is slow enough to watch blocks
    move. Running "ps aux" takes nearly one third of a second for total
    time. Total number of processes is ~40.

    Jan 31 22:31:51 nifty kernel: kapm-idled S CBF77F94 4124 3
    1 (L-TLB) 4 2
    Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148]
    [process_timeout+0/72] [apm_mainloop+221/256] [apm+668/692]
    [kernel_thread+31/56] [kernel_thread+40/56]

    Jan 31 22:31:51 nifty kernel: kswapd S CBF75FAC 5704 4
    1 (L-TLB) 5 3
    Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148]
    [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92]
    [kswapd+213/244] [kernel_thread+40/56]

    Jan 31 22:31:52 nifty kernel: bdflush S CBF70000 5912 6
    1 (L-TLB) 7 5
    Jan 31 22:31:52 nifty kernel: Call Trace: [bdflush+206/216]

    In the fourth snapshot, I have put xmms in STOP state again inside the
    memory shortage, memory is at 4800 free buffers/cache and 1592 free mem.

    As I entered this shortage period I started a 'ps -eo ... > file' to try
    and record data there. This is the only disk activity happening. Load
    is ~4.00. I have now killed the ps.

    Load has dropped significantly and I have tolerable but quite laggy user
    input responsiveness now.

    Memory is currently 4900/1588 like above. Load is about 2.00 and will
    continue dropping if I don't do anything. Any processes I exec which
    need to be loaded from disk take several seconds. I.e. 'uptime' takes
    about 4 seconds to execute.

    Snapshot #5 will be the last one and I will reboot. Once memory is
    freed from xmms (back to 150megs free), everything is peachy.


    There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
    The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:26    [W:0.023 / U:8.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site