Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934290AbZKXWlm (ORCPT ); Tue, 24 Nov 2009 17:41:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934105AbZKXWlm (ORCPT ); Tue, 24 Nov 2009 17:41:42 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]:41713 "EHLO zrtps0kp.nortel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933988AbZKXWll (ORCPT ); Tue, 24 Nov 2009 17:41:41 -0500 Message-ID: <4B0C60A1.6030509@nortel.com> Date: Tue, 24 Nov 2009 16:39:29 -0600 From: "Chris Friesen" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Andi Kleen CC: Eyal Lotem , LKML Subject: Re: [RFC] Using "page credits" as a solution for common thrashing scenarios References: <87aaybwrny.fsf@basil.nowhere.org> In-Reply-To: <87aaybwrny.fsf@basil.nowhere.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2009 22:41:35.0303 (UTC) FILETIME=[46ED7570:01CA6D57] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1420 Lines: 34 On 11/24/2009 03:15 PM, Andi Kleen wrote: > Eyal Lotem 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/