lkml.org 
[lkml]   [2004]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: why swap at all?
    Buddy Lumpkin wrote:
    >>But swap behaviour kills performance even when memory is more than
    >>adequate. Consider building a DVD image in a 4GB system. The i/o forces
    >>all of the unused programs out, in spite of the fact that an extra 100MB
    >>doesn't make a measurable difference in performance. But when I click
    >>Mozilla paging most of it in from disk make a big difference in
    >>performance to the user.
    >
    >
    >
    > We really need a server option. Something that ages out file backed pages
    > naturally with less overhead than kswapd. One method would be to keep the
    > pagecache on it's own list, and move pages to the head of the list any time
    > they are modified or referenced, and reclaim from the tail.
    >
    > All pages on this list can be considered as "free memory", because any new
    > memory requests would just cause pages to be evicted from the tail of the
    > list.
    >
    > Anonymous memory would *not* be on this list. This way any time anonymous
    > memory is allocated, the pages can be readily stolen from the pagecache
    > list.
    >
    > Lastly one nifty configuration parameter that could exist as a knob for
    > sys-admins is the ability to tell the VM not to add file backed pages with
    > the execute bit set to the page cache list but rather, leave them to be
    > reclaimed if kswapd wakes up in a true low memory situation (pagecache is
    > exhausted and memory is still low). This would require a sys-admin to make
    > sure only executables have the execute bit set and "data files", etc... do
    > not have the execute bit set.

    Or have the exec() call set a "part of a process" flag. That means that
    if I read an executable in as data it doesn't get locked, other than
    what part might be in my i/o buffers. And mmap can produce different
    effects than read/write which may be good, if they are GOOD different
    effects ;-) Before you ask, thing 'strings' as why avg user does this.

    But I fail to make my point... I want to limit how much memory is used
    for i/o buffers, cache, or anything else which will produce memory
    pressure of my programs. The quick solution might be just a number from
    the admin, like the 2.2 patch, but some kernel logic to understand that
    while 20MB is much better than 10MB in a tiny system, 2GB is not a lot
    better than 1GB in a large memory system, and having a sync() bog the
    system for tens of seconds is undesirable. Well, maybe some folks don't
    agree, it could be that the admin set limit is really the way to go.

    I regard this as a desktop issue, trading some i/o performance to keep
    window changes fast.
    >
    >
    > A system that works like this is nice for the following reasons:
    >
    > 1) The system administrator can size a system so that all programs
    > Safely run within physical RAM. Extra RAM
    > Could be added and sized based on the need
    > for caching files.
    >
    > 2) Anonymous pages (and possibly executable if you read
    > the last paragraph above) will only be evicted if kswapd is
    > awaken due to a true memory shortage (1/128th pagable memory?).
    >
    >
    > I like to view the VM system as always being full, because if enough unique
    > file system IO takes place, that is exactly what eventually happens. A
    > system that counts page cache as free memory and uses a gentler mechanism to
    > evict pages from the page cache would benefit IO bound servers significantly
    > IMHO.

    That's what would be nice with tuning, the admin can optimize what is
    important on that system. I am usually happy with what the system does
    on i/o, but I want my 500MB or so of programs to stay resident in a 2GB
    machine, and if that adds a ms or two to i/o I can live with it, so that
    when I change windows it happens now, not eventually. And I bet there
    are a lot of others who would like better response to focus changes aswell.

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me
    -
    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:03    [W:0.028 / U:60.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site