From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
"Eric W. Biederman" <ebiederm+eric@npwt.net>,
Linux MM <linux-mm@kvack.org>
Subject: Re: More info: 2.1.108 page cache performance on low memory
Date: 25 Jul 1998 15:05:41 +0200 [thread overview]
Message-ID: <87d8au13oa.fsf@atlas.CARNet.hr> (raw)
In-Reply-To: Rik van Riel's message of "Fri, 24 Jul 1998 23:55:10 +0200 (CEST)"
Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:
> On 24 Jul 1998, Zlatko Calusic wrote:
>
> > > There's also a 'soft limit', or borrow percentage. Ultimately
> > > the minimum and maximum percentages should be 0 and 100 %
> > > respectively.
> >
> > Could you elaborate on "borrow" percentage? I have some trouble
> > understanding what that could be.
>
> It's an idea I stole from Digital Unix :)
>
> Basically, the cache is allowed to grow boundless, but is
> reclaimed until it reaches the borrow percentage when
> memory is short.
OK, I get it now. Looks good.
>
> The philosophy behind is that caching the disk doesn't make
> much sense beyond a certain point.
>
I mostly agree.
> It's a primitive idea, but it seems to have saved Andrea's
> machine quite well (with the additional patch).
>
> I admit your patch (multiple aging) should work even better,
> but in order to do that, we probably want to make it auto-tuning
> on the borrow percentage:
>
> - if page_cache_size > borrow + 5% --> add aging loop
> - if loads_of_disk_io and almost thrashing [*] --> remove aging loop
Yes, something like this could be worthwhile. I observed some strange
patterns of behaviour with aging loop, sometimes system is still too
aggresive, and sometimes you can't say if it's working at all.
Probably, some debbugging and profiling code should be added to see
what's goin' on there.
>
> [*] this thrashing can be measured by testing the cache hit/mis
> rate; if it falls below (say) 50% we could consider thrashing.
That probably wouldn't work as well as you expect. Problem is again
with that arbitrary 50%. I had code in kernel that reported
buffer/page cache hit ratio and was surprised that for both caches it
was > 90%. And that was on 5MB machine. Can you imagine? :)
>
> (50% should be a good rate for an aging cache, and the amount
> of loops is trimmed quickly enough when we grow anyway. This
> mechanism could make a nice somewhat adjusting trimming
> mechanism. Expect a patch soon...)
>
I'll be glad to test a patch, but I'm not that convinced that this is
really a good idea. But, then again I have nothing against it.
Keep up the good work!
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
Crime doesn't pay... does that mean my job is a crime?
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1998-07-25 13:06 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-13 16:53 Stephen C. Tweedie
1998-07-13 18:08 ` Eric W. Biederman
1998-07-13 18:29 ` Zlatko Calusic
1998-07-14 17:32 ` Stephen C. Tweedie
1998-07-16 12:31 ` Zlatko Calusic
1998-07-14 17:30 ` Stephen C. Tweedie
1998-07-18 1:10 ` Eric W. Biederman
1998-07-18 13:28 ` Zlatko Calusic
1998-07-18 16:40 ` Eric W. Biederman
1998-07-20 9:15 ` Zlatko Calusic
1998-07-22 10:40 ` Stephen C. Tweedie
1998-07-23 10:06 ` Zlatko Calusic
1998-07-23 12:22 ` Stephen C. Tweedie
1998-07-23 14:07 ` Zlatko Calusic
1998-07-23 17:18 ` Stephen C. Tweedie
1998-07-23 19:33 ` Zlatko Calusic
1998-07-27 10:57 ` Stephen C. Tweedie
1998-07-26 14:49 ` Eric W Biederman
1998-07-27 11:02 ` Stephen C. Tweedie
1998-08-02 5:19 ` Eric W Biederman
1998-08-17 13:57 ` Stephen C. Tweedie
1998-08-17 15:35 ` Stephen C. Tweedie
1998-08-20 12:40 ` Eric W. Biederman
1998-07-20 15:58 ` Stephen C. Tweedie
1998-07-22 10:36 ` Stephen C. Tweedie
1998-07-22 18:01 ` Rik van Riel
1998-07-23 10:59 ` Stephen C. Tweedie
1998-07-22 10:33 ` Stephen C. Tweedie
1998-07-23 10:59 ` Zlatko Calusic
1998-07-23 12:23 ` Stephen C. Tweedie
1998-07-23 15:06 ` Zlatko Calusic
1998-07-23 15:17 ` Benjamin C.R. LaHaise
1998-07-23 15:25 ` Zlatko Calusic
1998-07-23 17:27 ` Benjamin C.R. LaHaise
1998-07-23 19:17 ` Dr. Werner Fink
1998-07-23 17:12 ` Stephen C. Tweedie
1998-07-23 17:42 ` Zlatko Calusic
1998-07-23 19:12 ` Dr. Werner Fink
1998-07-27 10:40 ` Stephen C. Tweedie
1998-07-23 19:51 ` Rik van Riel
1998-07-24 11:21 ` Zlatko Calusic
1998-07-24 14:25 ` Rik van Riel
1998-07-24 17:01 ` Zlatko Calusic
1998-07-24 21:55 ` Rik van Riel
1998-07-25 13:05 ` Zlatko Calusic [this message]
1998-07-27 10:54 ` Stephen C. Tweedie
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=87d8au13oa.fsf@atlas.CARNet.hr \
--to=zlatko.calusic@carnet.hr \
--cc=H.H.vanRiel@phys.uu.nl \
--cc=ebiederm+eric@npwt.net \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
/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