[lkml]   [1997]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Swapping (Was: Werner's latest patch and my News server)
    "Dr. Werner Fink" <> writes:
    > Note: If one combines your state fix in try_to_free_page() with the
    > buffer/swapping of David any system becomes unusable by simply running
    > and using the system. This is the conclusion out of the early patch attempts
    > I've done.
    I have been running 2.0.31pre2+your patch with the old state code. I saw a
    sigstopped process which blocked half my real memory but that wasn't swapped
    out _at_all_ while the system was busy thrashing its file system buffers.

    Sorry, but that's not a situation I can live with.

    I don't know how or why the kernel could ever become unstable just because
    we try swapping out a few pages once in a while instead of waiting until
    the buffer cache is effectively gone because RAM is full. All I know is
    that the code as it is now thrashes the buffer cache as soon as you run
    something like a Netnews server under conditions where 2.0.29 churned along
    quite happily.

    > ... it's trivial but if two processes have more than the half physical
    > memory over the most time and the system performance needs ram ...
    > it's a `Binsenweisheit'.
    Not in my situation. squid doesn't really need half the RAM (the system has
    96 MBytes), it runs quite well with an RSS of ten MBytes or so. Once I
    reapplied my state code fix, those 40 MBytes actually got swapped out
    instead of sitting there and doing nothing.
    Ditto for INN, which now uses 10 Mbytes (and another 20 on swap) instead of
    25 MBytes in core. News processing speed is up; the 150 MBytes of
    compressed newsbatches I've accumulated with the old code during the last
    few days are down to 100 MBytes.

    I spent the last half hour playing around with swapctl parameters and did
    manage to get the Netnews article processing speed almost back to 2.0.29
    levels. Without my state fix, the thing refused to do more than a third of
    that, and swapctl changes didn't have any effect at all (not surprisingly,
    since the machine wasn't swapping).

    Right now vmstat shows 10 swap and 50 block I/O operations per second with
    vmstat and runs reasonably well. Before applying my patch, it was zero
    swap, 80 block, and the thing was slow like molasses.

    The system is still not fast enough for my taste, but I can live with it
    until the real problem is found; 2.0.29 would have eaten those 150 MBytes
    during lunch break (OK, OK, almost...).

    NB: I'm only talking about article processing speed here. Interactive
    response time doesn't change much one way or the other.

    Matthias Urlichs

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