public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Parag Warudkar <kernel-stuff@comcast.net>
To: "linux-kernel" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: [PATCH 2.6.11-rc4] oom_kill.c: Kill obvious processes first
Date: Fri, 25 Feb 2005 00:24:30 -0500	[thread overview]
Message-ID: <200502250024.30450.kernel-stuff@comcast.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]


oom_kill.c misses very obvious targets - For example, a process occupying > 
80% memory, not superuser and not having hardware access gets ignored by it. 
Logically, such a process, if killed , is going to make things return to 
normal thereby eliminating the need for oom killer to further scan for more 
processes.

This patch calculates the approximate integer percentage of memory occupied by 
the process by looking at num_physpages and p->mm->total_vm. If this process 
is not super user and doesn't have hardware access, and the percentage of 
occupied memory is more than 60%, it immediately selects this process for 
killing by returning unusually high points from badness().

Without this patch, when KDevelop running as non root user gobbles up 90% 
memory, the OOM killer kills many other irrelevant processes but not KDevelop 
And machine never recovers.. (Pls see LKML for my previous message with 
subject "2.6.11-rc4 OOM Killer - Kill the Innocent".) 

With this patch OOM killer immediately kills kdevelop and machine recovers.

Signed-off-by: Parag Warudkar <kernel-stuff@comcast.net>

[-- Attachment #2: oom_kill.c.patch --]
[-- Type: text/x-diff, Size: 1924 bytes --]

--- linux-orig/mm/oom_kill.c	2005-02-23 20:03:11.000000000 -0500
+++ linux-2.6.10/mm/oom_kill.c	2005-02-25 00:21:20.000000000 -0500
@@ -44,8 +44,10 @@
 
 unsigned long badness(struct task_struct *p, unsigned long uptime)
 {
-	unsigned long points, cpu_time, run_time, s;
+	unsigned long points, cpu_time, run_time, s, pct_occ;
+	extern unsigned long num_physpages;
 	struct list_head *tsk;
+	int is_superuser=0, has_hwaccess=0;
 
 	if (!p->mm)
 		return 0;
@@ -55,6 +57,39 @@
 	 */
 	points = p->mm->total_vm;
 
+	if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_ADMIN) ||
+				p->uid == 0 || p->euid == 0) 
+	{
+		is_superuser=1;
+
+	}
+	
+	if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
+		has_hwaccess=1;
+	}
+	
+	if(is_superuser || has_hwaccess)
+		goto skip_pct_chk;
+
+	/* If the process 
+	 * a. Does not belong to superuser
+	 * b. Does not have hardware access, and
+	 * c. Occupies more than or equal to 50% memory 
+	 * it is a very likely candidate to kill.
+	 */
+	pct_occ = points*100 / num_physpages;
+
+	if (pct_occ >= 60) {
+#ifdef DEBUG	
+		printk(KERN_DEBUG "Process %s with PID %d occupied more
+				 than 60% memory\n", p->comm, p->pid);
+#endif
+		/* Return unusually high number to make sure this process
+		 * gets killed
+		 */
+		return points*pct_occ;
+	}
+	skip_pct_chk:	
 	/*
 	 * Processes which fork a lot of child processes are likely
 	 * a good choice. We add the vmsize of the childs if they
@@ -99,8 +134,7 @@
 	 * Superuser processes are usually more important, so we make it
 	 * less likely that we kill those.
 	 */
-	if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_ADMIN) ||
-				p->uid == 0 || p->euid == 0)
+	if (is_superuser)
 		points /= 4;
 
 	/*
@@ -109,7 +143,7 @@
 	 * tend to only have this flag set on applications they think
 	 * of as important.
 	 */
-	if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO))
+	if (has_hwaccess)
 		points /= 4;
 
 	/*

             reply	other threads:[~2005-02-25  5:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-25  5:24 Parag Warudkar [this message]
2005-02-28 22:30 ` [PATCH 2.6.11-rc4] oom_kill.c: Kill obvious processes first Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2005-03-01  0:55 Parag Warudkar

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=200502250024.30450.kernel-stuff@comcast.net \
    --to=kernel-stuff@comcast.net \
    --cc=akpm@osdl.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox