lkml.org 
[lkml]   [2004]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ~500 megs cached yet 2.6.5 goes into swap hell
    On Wed, Apr 28, 2004 at 08:19:24PM -0700, Andrew Morton wrote:
    > What you discuss above is just an implementation detail. Forget it. What
    > are the requirements? Thus far I've seen
    >
    > a) updatedb causes cache reclaim
    >
    > b) updatedb causes swapout
    >
    > c) prefer that openoffice/mozilla not get paged out when there's heavy
    > pagecache demand.
    >
    > For a) we don't really have a solution. Some have been proposed but they
    > could have serious downsides.
    >
    > For b) and c) we can tune the pageout-vs-cache reclaim tendency with
    > /proc/sys/vm/swappiness, only nobody seems to know that.
    >
    > What else is there?

    What I want is for purely sequential workloads which far exceed cache
    size (dd, updatedb, tar czf /backup/home.nightly.tar.gz /home) to avoid
    thrashing my entire desktop out of memory. I DON'T CARE if the tar
    completed in 45 minutes rather than 80. (It wouldn't, anyways, because
    it only needs about 5 MB of cache to get every bit of the speedup it was
    going to get.) But the additional latency when I un-xlock in the
    morning is annoying, and there is no benefit.

    For a more useful example, ideally I *should not be able to tell* that
    "dd if=/hde1 of=/hdf1" is running. [1] There is *no* benefit to cacheing
    more than about 2 pages, under this workload. But with current kernels,
    IME, that workload results in a gargantuan buffer cache and lots of
    swapout of apps I was using 3 minutes ago. I've taken to walking away
    for some coffee, coming back when it's done, and "sudo swapoff
    /dev/hda3; sudo swapon -a" to avoid the latency that is so annoying when
    trying to use bloaty apps.

    [1] obviously I'll see some slowdown due to interrupts and PCI
    bandwidth; that's not what I'm railing against, here.

    -andy
    -
    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 14:02    [W:3.277 / U:0.668 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site