From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Benjamin Redelings I <bredelin@ucsd.edu>,
linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: Re: [2.1.130-3] Page cache DEFINATELY too persistant... feature?
Date: 27 Nov 1998 20:58:38 +0100 [thread overview]
Message-ID: <8767c0q55d.fsf@atlas.CARNet.hr> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of "Fri, 27 Nov 1998 16:02:51 GMT"
"Stephen C. Tweedie" <sct@redhat.com> writes:
> Hi,
>
> Looks like I have a handle on what's wrong with the 2.1.130 vm (in
> particular, its tendency to cache too much at the expense of
> swapping).
>
> The real problem seems to be that shrink_mmap() can fail for two
> completely separate reasons. First of all, we might fail to find a
> free page because all of the cache pages we find are recently
> referenced. Secondly, we might fail to find a cache page at all.
>
> The first case is an example of an overactive, large cache; the second
> is an example of a very small cache. Currently, however, we treat
> these two cases pretty much the same. In the second case, the correct
> reaction is to swap, and 2.1.130 is sufficiently good at swapping that
> we do so, heavily. In the first case, high cache throughput, what we
> really _should_ be doing is to age the pages more quickly. What we
> actually do is to swap.
>
> On reflection, there is a completely natural way of distinguishing
> between these two cases, and that is to extend the size of the
> shrink_mmap() pass whenever we encounter many recently touched pages.
> This is easy to do: simply restricting the "count_min" accounting in
> shrink_mmap to avoid including salvageable but recently-touched pages
> will automatically cause us to age faster as we encounter more touched
> pages in the cache.
>
> The patch below both makes sense from this perspective and seems to
> work, which is always a good sign! Moreover, it is inherently
> self-tuning. The more recently-accessed cache pages we encounter, the
> faster we will age the cache.
>
Hi!
Yesterday, I was trying to understand the very same problem you're
speaking of. Sometimes kswapd decides to swapout lots of things,
sometimes not.
I applied your patch, but it didn't solve the problem.
To be honest, things are now even slightly worse. :(
Sample output of vmstat 1, while copying lots of stuff to /dev/null:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 1 0 23696 1656 3276 25128 0 0 6425 62 304 284 20 34 46
2 0 1 23696 1444 3276 25344 0 0 9265 0 325 315 26 49 26
2 0 1 23696 1384 3276 25408 0 0 10507 0 333 365 20 55 25
3 0 1 23696 1408 3276 25388 0 0 10758 0 334 336 23 55 23
2 0 0 23696 1672 3276 25132 0 0 9965 0 321 328 23 50 27
3 0 1 23692 1408 3276 25384 4 0 9582 5 315 339 23 45 32
2 0 1 23692 1400 3276 25392 0 0 9794 0 323 336 21 47 32
4 0 1 23788 1436 3276 25460 0 96 9146 24 335 325 24 44 32
2 0 1 23788 1152 3276 25736 0 0 9763 0 321 326 23 46 31
1 1 1 24760 1356 3276 26504 4 976 1326 244 349 247 21 14 65
2 0 1 25916 932 3276 28092 16 1192 1621 306 371 271 23 8 69
1 1 1 26888 976 3276 29012 12 1056 993 264 335 289 19 9 72
2 0 0 28208 1552 3276 29756 0 1320 750 330 380 276 10 6 84
1 1 1 29224 1140 3276 31176 4 1040 1444 260 357 270 33 13 54
2 0 1 30412 1200 3276 32296 8 1196 1131 304 405 274 20 8 73
3 0 1 31412 1112 3276 33384 0 1000 1092 250 344 269 18 11 71
2 0 1 32396 532 3276 34948 0 984 1570 246 359 242 19 11 70
0 3 1 33504 1476 3276 35128 0 1128 197 282 314 279 15 4 81
3 0 1 35080 648 3276 37520 0 1612 2443 403 299 325 24 13 63
2 0 1 37116 736 3276 39468 4 2276 2077 575 314 352 8 14 78
1 1 1 39368 1352 3276 41092 0 2300 1793 575 299 352 36 13 51
1 1 1 41516 644 3276 43940 0 2356 3071 589 317 353 20 18 62
1 0 2 43696 1220 3276 45544 4 2420 1848 605 321 354 20 12 68
0 2 1 44980 532 3276 47512 16 1628 2306 407 318 328 22 14 64
3 0 1 46512 1000 3276 48576 24 1832 1353 459 314 344 22 12 66
2 1 0 46932 1648 3340 48284 88 888 3131 222 344 379 23 13 64
2 1 0 46672 1656 3276 48068 108 0 6313 0 476 369 19 30 51
3 1 0 46592 19812 3276 29840 156 0 4054 0 324 357 37 22 41
I'll do some more investigation this night.
Regards,
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
So much time, and so little to do.
--
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-11-27 1:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199811261236.MAA14785@dax.scot.redhat.com>
[not found] ` <Pine.LNX.3.95.981126094159.5186D-100000@penguin.transmeta.com>
1998-11-27 16:02 ` [2.1.130-3] Page cache DEFINATELY too persistant... feature? Stephen C. Tweedie
1998-11-27 17:19 ` Chip Salzenberg
1998-11-27 18:31 ` Linus Torvalds
1998-11-27 19:58 ` Zlatko Calusic [this message]
1998-11-30 11:15 ` Stephen C. Tweedie
1998-11-30 23:13 ` Zlatko Calusic
1998-11-30 12:37 ` Rik van Riel
1998-11-30 15:12 ` Zlatko Calusic
1998-11-30 19:29 ` Rik van Riel
1998-11-30 22:27 ` Zlatko Calusic
1998-11-30 23:11 ` Rik van Riel
1998-11-30 20:20 ` Andrea Arcangeli
1998-11-30 22:28 ` Zlatko Calusic
1998-11-28 7:31 ` Eric W. Biederman
1998-11-30 11:13 ` Stephen C. Tweedie
1998-11-30 15:08 ` Rik van Riel
1998-11-30 21:40 ` Eric W. Biederman
1998-11-30 22:00 ` Eric W. Biederman
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=8767c0q55d.fsf@atlas.CARNet.hr \
--to=zlatko.calusic@carnet.hr \
--cc=bredelin@ucsd.edu \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.