From: John Sigler <linux.kernel@free.fr>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Helge Hafting <helge.hafting@aitel.hist.no>,
Andrea Arcangeli <andrea@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: Runaway process and oom-killer
Date: Thu, 14 Jun 2007 12:01:57 +0200 [thread overview]
Message-ID: <46711215.4070108@free.fr> (raw)
In-Reply-To: <467008E9.7070902@nortel.com>
Chris Friesen wrote:
> Helge Hafting wrote:
>
>> My guess:
>> Something needs memory but finds there is none to be had
>> oom-killer is invoked and targets myapp.
>> myapp takes some time to die. Particularly, the memory it uses
>> isn't freed up instantly.
>
> Has anyone considered actually bumping up the priority of the task being
> killed so that it gets to run and free up its resources in a timely manner?
On this system,
myapp runs in SCHED_RR with priority 80.
IRQ handlers run in SCHED_FIFO with priority 50.
# ps -eo comm,class,rtprio,ni,pri --sort -rtprio
COMMAND CLS RTPRIO NI PRI
posix_cpu_timer FF 99 - 139
myapp RR 80 - 120
softirq-high/0 FF 50 - 90
softirq-timer/0 FF 50 - 90
softirq-net-tx/ FF 50 - 90
softirq-net-rx/ FF 50 - 90
softirq-block/0 FF 50 - 90
softirq-tasklet FF 50 - 90
softirq-sched/0 FF 50 - 90
softirq-hrtimer FF 50 - 90
softirq-rcu/0 FF 50 - 90
IRQ-7 FF 50 - 90
IRQ-8 FF 50 - 90
IRQ-14 FF 50 - 90
IRQ-12 FF 50 - 90
IRQ-1 FF 50 - 90
IRQ-10 FF 50 - 90
IRQ-11 FF 50 - 90
IRQ-5 FF 50 - 90
IRQ-3 FF 50 - 90
IRQ-4 FF 50 - 90
events/0 FF 1 - 41
init TS - 0 24
desched/0 TS - -10 34
khelper TS - -5 29
kthread TS - -5 27
kblockd/0 TS - -5 21
kacpid TS - -5 19
kseriod TS - -5 29
pdflush TS - 0 17
pdflush TS - 0 24
kswapd0 TS - -5 23
flush_filesd/0 TS - -5 29
aio/0 TS - -5 22
syslogd TS - 0 21
klogd TS - 0 21
sshd TS - 0 21
acpid TS - 0 16
agetty TS - 0 24
agetty TS - 0 21
agetty TS - 0 21
agetty TS - 0 21
[...]
How do the scheduling class and priority of the process come into play
when the kernel comes to reclaim memory after the oom-killer has decided
to snipe that particular process?
> We've done some experimenting with actually putting it in SCHED_RR and
> it seems to help (in the case of other busy SCHED_RR tasks on the
> system). Admittedly we have an older kernel, so behaviour may be
> different now.
Thanks for sharing your experience.
Regards.
next prev parent reply other threads:[~2007-06-14 10:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-13 8:49 Runaway process and oom-killer John Sigler
2007-06-13 9:08 ` Andrea Arcangeli
2007-06-13 9:20 ` John Sigler
2007-06-13 13:29 ` Helge Hafting
2007-06-13 15:10 ` Chris Friesen
2007-06-13 15:26 ` Andrea Arcangeli
2007-06-14 10:01 ` John Sigler [this message]
2007-06-14 9:43 ` John Sigler
2007-06-14 12:56 ` Helge Hafting
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=46711215.4070108@free.fr \
--to=linux.kernel@free.fr \
--cc=andrea@suse.de \
--cc=cfriesen@nortel.com \
--cc=helge.hafting@aitel.hist.no \
--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.