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.189 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site