From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: vedran.furac@gmail.com
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
hugh.dickins@tiscali.co.uk, akpm@linux-foundation.org,
rientjes@google.com
Subject: Re: Memory overcommit
Date: Wed, 28 Oct 2009 03:02:39 +0900 [thread overview]
Message-ID: <2f11576a0910271102g60dcdd1dj8f3df213bc64a51d@mail.gmail.com> (raw)
In-Reply-To: <4AE72A0D.9070804@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
>> I attached a scirpt for checking oom_score of all exisiting process.
>> (oom_score is a value used for selecting "bad" processs.")
>> please run if you have time.
>
> 96890 21463 VirtualBox // OK
> 118615 11144 kded4 // WRONG
> 127455 11158 knotify4 // WRONG
> 132198 1 init // WRONG
> 133940 11151 ksmserver // WRONG
> 134109 11224 audacious2 // Audio player, maybe
> 145476 21503 VirtualBox // OK
> 174939 11322 icedove-bin // thunderbird, maybe
> 178015 11223 akregator // rss reader, maybe
> 201043 22672 krusader // WRONG
> 212609 11187 krunner // WRONG
> 256911 24252 test // culprit, malloced 1GB
> 1750371 11318 run-mozilla.sh // tiny, parent of firefox threads
> 2044902 11141 kdeinit4 // tiny, parent of most KDE apps
Verdran, I made alternative improvement idea. Can you please mesure
badness score
on your system?
Maybe your culprit process take biggest badness value.
Note: this patch change time related thing. So, please drink a cup of
coffee before mesurement.
small rest time makes correct test result.
[-- Attachment #2: 0001-oom-oom-score-bonus-by-run_time-use-proportional-va.patch --]
[-- Type: application/octet-stream, Size: 3025 bytes --]
From 047e6647f580a7c9bed2ac547bc9b15154d5da4c Mon Sep 17 00:00:00 2001
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date: Wed, 28 Oct 2009 02:25:01 +0900
Subject: [PATCH] oom: oom-score bonus by run_time use proportional value
Currently, oom-score bonus by run_time use the fomula of "sqrt(sqrt(runtime / 1024)))".
It mean process got 1/3 times oom-score per day. This feature exist for protect sevaral
important system daemon.
However, typical desktop user reboot the system everyday. then its bonus is too small.
This bonus only works well on server systems. IOW typical uptime strongly depend on
use-case. it shouldn't use for oom modifier.
Instead, This patch use proportional run_time value against uptime.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
fs/proc/base.c | 1 +
mm/oom_kill.c | 26 +++++++++++++++-----------
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 837469a..17d6fd4 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -446,6 +446,7 @@ static int proc_oom_score(struct task_struct *task, char *buffer)
struct timespec uptime;
do_posix_clock_monotonic_gettime(&uptime);
+ monotonic_to_bootbased(&uptime);
read_lock(&tasklist_lock);
points = badness(task->group_leader, uptime.tv_sec);
read_unlock(&tasklist_lock);
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index ea2147d..3c1b3a3 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -69,10 +69,10 @@ static int has_intersects_mems_allowed(struct task_struct *tsk)
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)
*/
-
unsigned long badness(struct task_struct *p, unsigned long uptime)
{
- unsigned long points, cpu_time, run_time;
+ unsigned long points, cpu_time;
+ unsigned long run_time = 0;
struct mm_struct *mm;
struct task_struct *child;
int oom_adj = p->signal->oom_adj;
@@ -130,17 +130,20 @@ unsigned long badness(struct task_struct *p, unsigned long uptime)
utime = cputime_to_jiffies(task_time.utime);
stime = cputime_to_jiffies(task_time.stime);
cpu_time = (utime + stime) >> (SHIFT_HZ + 3);
-
-
- if (uptime >= p->start_time.tv_sec)
- run_time = (uptime - p->start_time.tv_sec) >> 10;
- else
- run_time = 0;
-
if (cpu_time)
points /= int_sqrt(cpu_time);
- if (run_time)
- points /= int_sqrt(int_sqrt(run_time));
+
+ if (uptime <= p->real_start_time.tv_sec) {
+ /* Baby process may be not so important. */
+ points *= 2;
+ } else {
+ run_time = (uptime - p->real_start_time.tv_sec);
+ if (!run_time)
+ run_time = 1;
+
+ run_time = ((run_time * 100) / uptime) + 1;
+ points /= int_sqrt(run_time);
+ }
/*
* Niced processes are most likely less important, so double
@@ -233,6 +236,7 @@ static struct task_struct *select_bad_process(unsigned long *ppoints,
*ppoints = 0;
do_posix_clock_monotonic_gettime(&uptime);
+ monotonic_to_bootbased(&uptime);
for_each_process(p) {
unsigned long points;
--
1.6.2.5
next prev parent reply other threads:[~2009-10-27 18:02 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <hav57c$rso$1@ger.gmane.org>
[not found] ` <20091013120840.a844052d.kamezawa.hiroyu@jp.fujitsu.com>
[not found] ` <hb2cfu$r08$2@ger.gmane.org>
[not found] ` <20091014135119.e1baa07f.kamezawa.hiroyu@jp.fujitsu.com>
2009-10-20 21:52 ` Vedran Furač
2009-10-26 1:55 ` KAMEZAWA Hiroyuki
2009-10-26 16:16 ` Vedran Furač
2009-10-27 3:22 ` KAMEZAWA Hiroyuki
2009-10-27 6:10 ` KOSAKI Motohiro
2009-10-27 6:34 ` Minchan Kim
2009-10-27 6:36 ` KAMEZAWA Hiroyuki
2009-10-27 6:55 ` Minchan Kim
2009-10-27 7:45 ` [RFC][PATCH] oom_kill: avoid depends on total_vm and use real RSS/swap value for oom_score (Re: " KAMEZAWA Hiroyuki
2009-10-27 7:56 ` Minchan Kim
2009-10-27 12:38 ` Andrea Arcangeli
2009-10-28 0:22 ` KAMEZAWA Hiroyuki
2009-10-28 0:45 ` Vedran Furač
2009-10-27 7:56 ` KAMEZAWA Hiroyuki
2009-10-27 8:14 ` Minchan Kim
2009-10-27 8:33 ` KAMEZAWA Hiroyuki
2009-10-27 8:52 ` Minchan Kim
2009-10-27 8:56 ` KAMEZAWA Hiroyuki
2009-10-27 17:41 ` Vedran Furač
2009-10-28 0:13 ` KAMEZAWA Hiroyuki
2009-10-27 18:39 ` Hugh Dickins
2009-10-27 18:47 ` Andrea Arcangeli
2009-10-28 0:32 ` KAMEZAWA Hiroyuki
2009-11-05 19:02 ` Pavel Machek
2009-10-28 0:28 ` KAMEZAWA Hiroyuki
2009-10-27 6:46 ` KOSAKI Motohiro
2009-10-27 6:56 ` Minchan Kim
2009-10-27 17:12 ` Vedran Furač
2009-10-27 18:02 ` KOSAKI Motohiro [this message]
2009-10-27 18:30 ` Vedran Furač
2009-10-27 20:44 ` Hugh Dickins
2009-10-27 21:04 ` David Rientjes
2009-10-28 0:08 ` Vedran Furač
2009-10-28 0:25 ` David Rientjes
2009-10-28 0:39 ` Vedran Furač
2009-10-28 4:08 ` David Rientjes
2009-10-28 4:55 ` KAMEZAWA Hiroyuki
2009-10-28 5:13 ` David Rientjes
2009-10-28 6:05 ` KAMEZAWA Hiroyuki
2009-10-28 6:17 ` David Rientjes
2009-10-28 6:20 ` KAMEZAWA Hiroyuki
2009-10-29 8:38 ` David Rientjes
2009-10-29 11:11 ` Vedran Furač
2009-10-29 19:53 ` David Rientjes
2009-10-29 23:48 ` KAMEZAWA Hiroyuki
2009-10-30 9:10 ` David Rientjes
2009-10-30 9:36 ` KAMEZAWA Hiroyuki
2009-11-03 20:49 ` David Rientjes
2009-11-04 0:50 ` KAMEZAWA Hiroyuki
2009-11-04 1:58 ` David Rientjes
2009-11-04 2:17 ` KAMEZAWA Hiroyuki
2009-11-04 3:10 ` David Rientjes
2009-11-04 3:19 ` KAMEZAWA Hiroyuki
2009-10-30 13:59 ` Vedran Furač
2009-10-30 19:24 ` David Rientjes
2009-11-02 19:58 ` Vedran Furač
2009-10-28 13:28 ` Vedran Furač
2009-10-28 20:10 ` David Rientjes
2009-10-29 3:05 ` Vedran Furač
2009-10-29 8:35 ` David Rientjes
2009-10-29 11:01 ` Vedran Furač
2009-10-29 19:42 ` David Rientjes
2009-10-30 13:53 ` Vedran Furač
2009-10-30 14:08 ` Thomas Fjellstrom
2009-10-30 15:13 ` Vedran Furač
2009-10-30 14:12 ` Andrea Arcangeli
2009-10-30 14:41 ` Vedran Furač
2009-10-30 15:15 ` Andrea Arcangeli
2009-10-30 16:24 ` Hugh Dickins
2009-11-02 19:56 ` Vedran Furač
2009-10-30 19:44 ` David Rientjes
2009-11-02 19:56 ` Vedran Furač
2009-10-28 0:43 ` KAMEZAWA Hiroyuki
2009-10-28 2:47 ` KOSAKI Motohiro
2009-10-28 3:17 ` KAMEZAWA Hiroyuki
2009-10-28 4:12 ` David Rientjes
2009-10-28 8:10 ` Hugh Dickins
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=2f11576a0910271102g60dcdd1dj8f3df213bc64a51d@mail.gmail.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=vedran.furac@gmail.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