From: John Richard Moser <nigelenki@comcast.net>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory compression (again). . help?
Date: Tue, 28 Feb 2006 12:02:09 -0500 [thread overview]
Message-ID: <44048211.2070906@comcast.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0602281123410.15105@cuia.boston.redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rik van Riel wrote:
> On Mon, 27 Feb 2006, John Richard Moser wrote:
>
>> Hmm, I can't see where the kernel checks to see which pages are least
>> used. . . . anyone good with the VM can point me in the right direction?
>
> Not completely written yet, but take a look at:
>
> http://linux-mm.org/PageOutKswapd
>
Wow nice. Confusing, but nice.
I'm currently peeking around vmscan.c, though I can't seem to tell quite
how the kernel knows what's hot and cold. I heard somewhere that when a
process doesn't use memory for like 5 days, the kernel knows better to
swap that instead of something it used 10 minutes ago. I'm not sure how
though, I don't think the kernel debugs memory access. My best guess is
when the page falls out of process TLB, the kernel is notified about it
and keeps these in order; and when it's faulted back into TLB, the
kernel is notified and moves it up to more recently used. Of course,
this would mean the kernel never invalidates stuff in the process' TLB
(working set), which doesn't make sense. Either way the inner workings
don't matter much to me; what I'm worried about is where it accounts for
this and more importantly what APIs it provides to query this information.
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEBIIQhDd4aOud5P8RAnxaAKCOreOPFYNokQzECFPpSAOCbzJsQgCggWav
AIZ+oU4AMRkdMGjp62xdqP0=
=TkEA
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2006-02-28 17:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-28 1:03 Memory compression (again). . help? John Richard Moser
2006-02-28 3:27 ` John Richard Moser
2006-02-28 5:20 ` Magnus Damm
2006-02-28 12:06 ` John Richard Moser
2006-02-28 16:24 ` Rik van Riel
2006-02-28 17:02 ` John Richard Moser [this message]
2006-02-28 4:00 ` Alexander E. Patrakov
2006-02-28 12:18 ` John Richard Moser
2006-02-28 12:38 ` Asbjørn Sannes
2006-02-28 16:06 ` John Richard Moser
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=44048211.2070906@comcast.net \
--to=nigelenki@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@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