All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Eyal Lotem <eyal.lotem@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Using "page credits" as a solution for common thrashing scenarios
Date: Tue, 24 Nov 2009 16:39:29 -0600	[thread overview]
Message-ID: <4B0C60A1.6030509@nortel.com> (raw)
In-Reply-To: <87aaybwrny.fsf@basil.nowhere.org>

On 11/24/2009 03:15 PM, Andi Kleen wrote:
> Eyal Lotem <eyal.lotem@gmail.com> writes:
> 
> Replying to an old email.
> 
>>   * I think it is wrong for the kernel to evict the 15 pages of the bash,
>>     xterm, X server's working set, as an example, in order for a
>>     misbehaving process to have 1000015 instead of 1000000 pages in its
>>     working set. EVEN if that misbehaving process is accessing its working
>>     set far more aggressively.
> 
> One problem in practice tends to be that it's hard to realiably detect
> that a process is misbehaving. The 1000000 page process might be your
> critical database, while the 15 page process is something very
> unimportant.

Quite a while ago now I proposed the ability for an app (with suitable
privileges) to register with the system the amount of memory it expected
to use.  As long as it was under that amount it would be immune to the
oom-killer.

We've been using this in production for some time now as we have several
very large memory footprint apps that otherwise become quite attractive
to the oom killer.

The oom_adj proc entry made this less of an issue so I never bothered
pushing it to mainline.

Chris

  reply	other threads:[~2009-11-24 22:41 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
2009-11-24 21:15 ` Andi Kleen
2009-11-24 22:39   ` Chris Friesen [this message]
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=4B0C60A1.6030509@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=andi@firstfloor.org \
    --cc=eyal.lotem@gmail.com \
    --cc=linux-kernel@vger.kernel.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 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.