public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: John Bradford <john@grabjohn.com>
Cc: "Rik van Riel" <riel@redhat.com>,
	"Lasse Kärkkäinen / Tronic" <tronic2@sci.fi>,
	linux-kernel@vger.kernel.org
Subject: Re: Some thoughts about cache and swap
Date: Wed, 09 Jun 2004 15:43:29 -0400	[thread overview]
Message-ID: <40C76861.4040600@tmr.com> (raw)
In-Reply-To: <200406060708.i5678PW4000272@81-2-122-30.bradfords.org.uk>

John Bradford wrote:
> Quote from Rik van Riel <riel@redhat.com>:
> 
>>On Sat, 5 Jun 2004, [UTF-8] Lasse K=C3=A4rkk=C3=A4inen / Tronic wrote:
>>
>>
>>>In order to make better use of the limited cache space, the following
>>>methods could be used:
>>
>>	[snip magic piled on more magic]
>>
>>I wonder if we should just bite the bullet and implement
>>LIRS, ARC or CART for Linux.  These replacement algorithms
>>should pretty much detect by themselves which pages are
>>being used again (within a reasonable time) and which pages
>>aren't.
> 
> 
> Is the current system really bad enough to make it worthwhile, though?

Yes! The current implementation just uses all the memory available, and 
pushes any programs not actively running out to disk. Click the window 
and go for coffee. On a small machine that's needed, but for almost any 
typical usage, desktop or server, pushing out programs to have 3.5GB of 
buffer instead of 3.0 doesn't help disk performance.

> Is there really much performance to be gained from tuning the 'limited' cache
> space, or will it just hurt as many or more systems than it helps?

I doubt it, but it would be nice to have a tuner the admin could use 
instead of trying to guess what the priority of program response and i/o 
response should be. So if I have a graphics program which might open an 
image (small file) and decompress it into 1500MB of raw image, I can set 
  the buffer space down to a GB or so (I assume that I do this on a 
machine fitted to such use) and get good response.

And even on a small machine with only 256MB or so, not having the 
overnight file check push all but the last 10-12MB of programs out of 
memory. That's the problem with the current system. As for hurting other 
systems, that's why a tuner would be nice.

With various patches things are getting better, don't think it isn't 
noticed and appreciated.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  parent reply	other threads:[~2004-06-09 19:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-05 14:40 Some thoughts about cache and swap Lasse Kärkkäinen / Tronic
2004-06-05 23:37 ` Rik van Riel
2004-06-06  7:08   ` John Bradford
2004-06-06  8:38     ` Christian Borntraeger
2004-06-09 18:13       ` Matt Mackall
2004-06-09 19:32         ` John Bradford
2004-06-09 19:32           ` Rik van Riel
2004-06-11 14:07             ` Jörn Engel
2004-06-12  1:50               ` Rik van Riel
2004-06-09 19:45       ` Bill Davidsen
2004-06-09 19:43     ` Bill Davidsen [this message]
2004-06-10  7:47       ` Buddy Lumpkin
2004-06-16 14:15       ` jlnance

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40C76861.4040600@tmr.com \
    --to=davidsen@tmr.com \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=tronic2@sci.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox