[lkml]   [2001]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Break 2.4 VM in five easy steps
    "Eric W. Biederman" wrote:
    > Derek Glidden <> writes:
    > > The problem I reported is not that 2.4 uses huge amounts of swap but
    > > that trying to recover that swap off of disk under 2.4 can leave the
    > > machine in an entirely unresponsive state, while 2.2 handles identical
    > > situations gracefully.
    > >
    > The interesting thing from other reports is that it appears to be kswapd
    > using up CPU resources. Not the swapout code at all. So it appears
    > to be a fundamental VM issue. And calling swapoff is just a good way
    > to trigger it.
    > If you could confirm this by calling swapoff sometime other than at
    > reboot time. That might help. Say by running top on the console.

    That's exactly what my original test was doing. I think it was Jeffrey
    Baker complaining about "swapoff" at reboot. See my original post that
    started this thread and follow the "five easy steps." :) I'm sucking
    down a lot of swap, although not all that's available which is something
    I am specifically trying to avoid - I wanted to stress the VM/swap
    recovery procedure, not "out of RAM and swap" memory pressure - and then
    running 'swapoff' from an xterm or a console.

    The problem with being able to see what's eating up CPU resources is
    that the whole machine stops responding for me to tell. consoles stop
    updating, the X display freezes, keyboard input is locked out, etc. As
    far as anyone can tell, for several minutes, the whole machine is locked
    up. (except, strangely enough, the machine will still respond to ping)
    I've tried running 'top' to see what task is taking up all the CPU time,
    but the system hangs before it shows anything meaningful. I have been
    able to tell that it hits 100% "system" utilization very quickly though.

    I did notice that the first thing sys_swapoff() does is call
    lock_kernel() ... so if sys_swapoff() takes a long time, I imagine
    things will get very unresponsive quickly. (But I'm not intimately
    familiar with the various kernel locks, so I don't know what
    granularity/atomicity/whatever lock_kernel() enforces.)

    #!/usr/bin/perl -w

    usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
    | extract_mpeg2 | mpeg2dec -
    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 12:54    [W:0.023 / U:41.764 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site