All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eyal Lotem <eyal.lotem@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Using "page credits" as a solution for common thrashing  scenarios
Date: Tue, 17 Nov 2009 23:19:33 +0200	[thread overview]
Message-ID: <b64f365b0911171319u122eaf4xdb9da98059f94b85@mail.gmail.com> (raw)
In-Reply-To: <4B0310CD.6050303@redhat.com>

> The real problematic details are in the data structures.
>
> How to organize the pages in-kernel?
>
> How does the kernel find the pages with the lowest
> score?  In the memory zone where memory needs
> to be freed...
>
> How can the kernel efficiently change the score of
> tens of thousands (or even millions) of pages at once,
> moving them to the right LRU list cheaply?
>
> Making page replacement scale to systems with
> hundreds of gigabytes of memory is a necessity, as
> is evicting the right kind of page (filesystem cache
> vs process page, etc).
>
> Within those constraints, it becomes very hard to
> implement a solution along your ideas.

I agree an implementation that reasonably addresses these concerns is far
from trivial.  I wouldn't give up on finding a way to implement it (or a
good approximation of it) so soon.

Before diving into the exact implementation details, I was wondering if I'm
getting some basic fact wrong -- would this solution (if possible to
implement with reasonable performance) truly mitigate this kind of
thrashing?

Eyal

  reply	other threads:[~2009-11-17 21:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-17 20:52 [RFC] Using "page credits" as a solution for common thrashing scenarios Eyal Lotem
2009-11-17 21:08 ` Rik van Riel
2009-11-17 21:19   ` Eyal Lotem [this message]
2009-11-24 21:15 ` Andi Kleen
2009-11-24 22:39   ` Chris Friesen
2010-06-08  9:45   ` Eyal Lotem

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=b64f365b0911171319u122eaf4xdb9da98059f94b85@mail.gmail.com \
    --to=eyal.lotem@gmail.com \
    --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 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.