[lkml]   [2006]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: la la la la ... swappiness
    We want it to swap less for this particular operation because it is low
    priority compared to the rest of what's going on inside the box.

    We've considered both artificially manipulating swap on the fly similar to
    your suggestion as well a parallel thread that pumps a 3 into drop_caches
    every few seconds while the update is running, but these seem too much like
    hacks for our liking. Mind you, if we don't have a choice we'll do what we
    need to get the job done but there's a nagging voice in our conscience that
    says keep looking for a more elegant solution and work *with* the kernel
    rather than working against it or trying to trick it into doing what we

    We've already disabled OOM so we can at least keep our testing alive while
    searching for a more elegant solution. Although we want to avoid swap in
    this particular instance for this particular reason, in our hearts we agree
    with Andrew that swap can be your friend and get you out of a jam once in a
    while. Even more, we'd like to leave OOM active if we can because we want to
    be told when somebody's not being a good memory citizen.

    Some background, what we've done is carve up a huge chunk of memory that is
    shared between three resident processes as write cache for a proprietary
    block system layout that is part of a scalable storage architecture
    currently capable of RAID 0, 1, 5 (soon 6) virtualized across multiple
    chassis's, essentially treating each machine as a "disk" and providing
    multipath I/O to multiple iSCSI targets as part of a grid/array storage
    solution. Whew! We also have a version that leverages a battery backed write
    cache for higher performance at an additional cost. This software is
    installable on any commodity platform with 4-N disks supported by Linux,
    I've even put it on an Optiplex with 4 simulated disks. Yawn ... yet another
    iSCSI storage solution, but this one scales linearly in capacity as well as
    performance. As such, we have no user level apps on the boxes and precious
    little disk to spare for additional swap so our version of the swap
    manipulation solution is to turn swap completely off for the duration of the

    I hope I haven't muddied things up even more but basically what we want to
    do is find a way to limit the number of cached pages for disk I/O on the OS
    filesystem, even if it drastically slows down the untar and verify process
    because the disk I/O we really care about is not on any of the OS

    Louis Aucoin

    -----Original Message-----
    From: Tim Schmielau []
    Sent: Sunday, December 03, 2006 2:47 PM
    To: Aucoin
    Cc: 'Andrew Morton';;;
    Subject: RE: la la la la ... swappiness

    On Sun, 3 Dec 2006, Aucoin wrote:

    > during tar extraction ... inactive pages reaches levels as high as ~375000

    So why do you want the system to swap _less_? You need to find some free
    memory for the additional processes to run in, and you have lots of
    inactive pages, so I think you want to swap out _more_ pages.

    I'd suggest to temporarily add a swapfile before you update your system.
    This can even help in bringing your memory use to the state before if you
    do it like this
    - swapon additional swapfile
    - update your database software
    - swapoff swap partition
    - swapon swap partition
    - swapoff additional swapfile


    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: 2006-12-04 00:59    [W:0.033 / U:5.948 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site