From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrea Arcangeli <arcangeli@mbox.queen.it>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Zlatko.Calusic@CARNet.hr, Rik van Riel <H.H.vanRiel@phys.uu.nl>,
linux-mm@kvack.org
Subject: Re: Page cache ageing: yae or nae? (fwd)
Date: Wed, 19 Aug 1998 16:19:47 +0100 [thread overview]
Message-ID: <199808191519.QAA07314@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.980817213852.335A-100000@dragon.bogus>
Hi,
On Mon, 17 Aug 1998 21:51:33 +0200 (CEST), Andrea Arcangeli
<arcangeli@mbox.queen.it> said:
>> It _does_ throw unused pages out, by making it far easier to age pages.
>> I thought that was what we wanted: is 2.0 performing badly for you? Is
>> this behaviour that bad?
> Bingo! After some minutes of testing seems work very well! I think we need
> this patch. The swapin/swapout seems avoided. Please Stephen forward your
> patch to Linus. I rediffed it since it doesn' t apply clean to 115.
Any other comments? Please? We are getting VERY close to 2.2, and we
need to have this resolved one way or the other. This patch works well
for me in all cases, but I really need to know if there are other cases
where the page cache ageing wins other than the readahead streaming.
--Stephen
----------------------------------------------------------------
--- linux/mm/filemap.c.orig Sat Aug 8 15:23:11 1998
+++ linux/mm/filemap.c Mon Aug 17 18:46:19 1998
@@ -172,10 +172,12 @@
break;
}
age_page(page);
+#if 0
if (page->age)
break;
if (page_cache_size * 100 < (page_cache.min_percent * num_physpages))
break;
+#endif
if (PageSwapCache(page)) {
delete_from_swap_cache(page);
return 1;
@@ -211,8 +213,8 @@
struct page * page;
int count_max, count_min;
- count_max = (limit<<2) >> (priority>>1);
- count_min = (limit<<2) >> (priority);
+ count_max = (limit<<1) >> (priority>>1);
+ count_min = (limit<<1) >> (priority);
page = mem_map + clock;
do {
@@ -327,6 +329,7 @@
*/
page = mem_map + MAP_NR(page_cache);
add_to_page_cache(page, inode, offset, hash);
+ set_bit(PG_referenced, &page->flags);
inode->i_op->readpage(file, page);
page_cache = 0;
}
----------------------------------------------------------------
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
parent reply other threads:[~1998-08-19 19:28 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <Pine.LNX.3.96.980817213852.335A-100000@dragon.bogus>]
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=199808191519.QAA07314@dax.dcs.ed.ac.uk \
--to=sct@redhat.com \
--cc=H.H.vanRiel@phys.uu.nl \
--cc=Zlatko.Calusic@CARNet.hr \
--cc=arcangeli@mbox.queen.it \
--cc=linux-mm@kvack.org \
/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