public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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-----

  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