* [RFC] Enabling other oom schemes
@ 2003-09-12 2:19 Rusty Lynch
2003-09-12 4:18 ` Rahul Karnik
2003-09-13 17:48 ` Jamie Lokier
0 siblings, 2 replies; 13+ messages in thread
From: Rusty Lynch @ 2003-09-12 2:19 UTC (permalink / raw)
To: riel; +Cc: linux-mm, linux-kernel
Over the years I have encountered various usage needs where the standard
oom_kill.c version of memory recovery was not the most ideal approach.
For example, some times it is better to just restart the system and
let a front end load balancer hand off the server load to another system.
Sometimes it might be worth the effort to write a very solution specific
oom handler.
Every now and then I hear rumblings of changing the way oom is handled by
using modules, or something. Since I was not able to uncover any actual
proposals, here is my quick attempt.
The patch below uses a notifier list for other components to register
to be called when an out of memory condition occurs. Basically:
* Added include/linux/oom_notifier.h and mm/oom_notifier.c
which add (un)registration functions and also provide the
out_of_memory() entry function that use to be held in mm/oom_kill.c
* Tweaked mm/oom_kill.c so that it can be enabled at build time.
(I wasn't able to make it build as a module because it is using
a few non-exported symbols in linux/mm/*)
* Added a very simple (in fact I'm sure too simple) mm/om_panic.c that
will panic on any oom condition
The patch works (although by looking over oom_kill.c, I'm sure oom_panic.c
will panic too soon), but it is really only a quick hack to see how people
feel about such an approach.
--rustyl
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1284 -> 1.1285
# include/linux/notifier.h 1.4 -> 1.5
# mm/oom_kill.c 1.24 -> 1.25
# mm/Makefile 1.24 -> 1.25
# init/Kconfig 1.28 -> 1.29
# (new) -> 1.1 mm/oom_panic.c
# (new) -> 1.1 include/linux/oom_notifier.h
# (new) -> 1.1 mm/oom_notifier.c
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/11 rusty@penguin.co.intel.com 1.1285
# Initial attempt at an oom notifier
# --------------------------------------------
#
diff -Nru a/include/linux/notifier.h b/include/linux/notifier.h
--- a/include/linux/notifier.h Thu Sep 11 18:34:47 2003
+++ b/include/linux/notifier.h Thu Sep 11 18:34:47 2003
@@ -66,5 +66,7 @@
#define CPU_OFFLINE 0x0005 /* CPU (unsigned)v offline (still scheduling) */
#define CPU_DEAD 0x0006 /* CPU (unsigned)v dead */
+#define OUT_OF_MEMORY 0x00007 /* Notify of critical memory shortage */
+
#endif /* __KERNEL__ */
#endif /* _LINUX_NOTIFIER_H */
diff -Nru a/include/linux/oom_notifier.h b/include/linux/oom_notifier.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/linux/oom_notifier.h Thu Sep 11 18:34:47 2003
@@ -0,0 +1,7 @@
+#ifndef _LINUX_OOM_NOTIFIER_H
+#define _LINUX_OOM_NOTIFIER_H
+
+int register_oom_notifier(struct notifier_block * nb);
+int unregister_oom_notifier(struct notifier_block * nb);
+
+#endif /* _LINUX_OOM_NOTIFIER_H */
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig Thu Sep 11 18:34:47 2003
+++ b/init/Kconfig Thu Sep 11 18:34:47 2003
@@ -162,6 +162,21 @@
This option enables access to kernel configuration file and build
information through /proc/config.gz.
+config OOM_KILL
+ bool "Kill process on out-of-memory conditions"
+ ---help---
+ This option enables the traditional oom_kill.c mechanism for
+ killing processes in an attempt to recover from an out-of-memory
+ condition.
+
+config OOM_PANIC
+ tristate "Panic on out-of-memory conditions"
+ ---help---
+ This option enables panic() to be called when a system is out of
+ memory. This feature along with /proc/sys/kernel/panic allows a
+ different behavior on out-of-memory conditions when the standard
+ behavior (killing processes in an attempt to recover) does not
+ make sense.
menuconfig EMBEDDED
bool "Remove kernel features (for embedded systems)"
diff -Nru a/mm/Makefile b/mm/Makefile
--- a/mm/Makefile Thu Sep 11 18:34:47 2003
+++ b/mm/Makefile Thu Sep 11 18:34:47 2003
@@ -7,8 +7,11 @@
mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
shmem.o vmalloc.o
-obj-y := bootmem.o filemap.o mempool.o oom_kill.o fadvise.o \
+obj-y := bootmem.o filemap.o mempool.o fadvise.o \
page_alloc.o page-writeback.o pdflush.o readahead.o \
- slab.o swap.o truncate.o vmscan.o $(mmu-y)
+ slab.o swap.o truncate.o vmscan.o oom_notifier.o \
+ $(mmu-y)
obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o
+obj-$(CONFIG_OOM_PANIC) += oom_panic.o
+obj-$(CONFIG_OOM_KILL) += oom_kill.o
diff -Nru a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c Thu Sep 11 18:34:47 2003
+++ b/mm/oom_kill.c Thu Sep 11 18:34:47 2003
@@ -20,6 +20,10 @@
#include <linux/swap.h>
#include <linux/timex.h>
#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/notifier.h>
+#include <linux/oom_notifier.h>
/* #define DEBUG */
@@ -230,7 +234,7 @@
/**
* out_of_memory - is the system out of memory?
*/
-void out_of_memory(void)
+static void out_of_memory_killer(void)
{
/*
* oom_lock protects out_of_memory()'s static variables.
@@ -305,3 +309,20 @@
out_unlock:
spin_unlock(&oom_lock);
}
+
+static int oom_notify(struct notifier_block * s, unsigned long v, void * d)
+{
+ out_of_memory_killer();
+ return 0;
+}
+
+static struct notifier_block oom_nb = {
+ .notifier_call = oom_notify,
+};
+
+static int __init init_oom_kill(void)
+{
+ printk("Registering oom_kill handler\n");
+ return register_oom_notifier(&oom_nb);
+}
+module_init(init_oom_kill);
diff -Nru a/mm/oom_notifier.c b/mm/oom_notifier.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/mm/oom_notifier.c Thu Sep 11 18:34:47 2003
@@ -0,0 +1,38 @@
+/*
+ * linux/mm/oom_notifier.c
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/vermagic.h>
+#include <linux/notifier.h>
+
+static DECLARE_MUTEX(notify_mutex);
+static struct notifier_block * oom_notify_list = 0;
+
+int register_oom_notifier(struct notifier_block * nb)
+{
+ int err;
+ down(¬ify_mutex);
+ err = notifier_chain_register(&oom_notify_list, nb);
+ up(¬ify_mutex);
+ return err;
+}
+EXPORT_SYMBOL(register_oom_notifier);
+
+int unregister_oom_notifier(struct notifier_block * nb)
+{
+ int err;
+ down(¬ify_mutex);
+ err = notifier_chain_unregister(&oom_notify_list, nb);
+ up(¬ify_mutex);
+ return err;
+}
+EXPORT_SYMBOL(unregister_oom_notifier);
+
+void out_of_memory(void)
+{
+ down(¬ify_mutex);
+ notifier_call_chain(&oom_notify_list, OUT_OF_MEMORY, 0);
+ up(¬ify_mutex);
+}
diff -Nru a/mm/oom_panic.c b/mm/oom_panic.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/mm/oom_panic.c Thu Sep 11 18:34:47 2003
@@ -0,0 +1,42 @@
+/*
+ * linux/mm/oom_panic.c
+ *
+ * This is a very simple component that will cause the kernel to
+ * panic on out-of-memory conditions. The behavior of panic can be
+ * further controlled with /proc/sys/kernel/panic.
+ *
+ * --rustyl <rusty@linux.intel.com>
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/notifier.h>
+#include <linux/oom_notifier.h>
+
+static int oom_notify(struct notifier_block * s, unsigned long v, void * d)
+{
+ panic("Out-Of-Memory");
+ return 0;
+}
+
+static struct notifier_block oom_nb = {
+ .notifier_call = oom_notify,
+};
+
+static int __init init_oom_panic(void)
+{
+ int err;
+ printk(KERN_INFO "Installing oom_panic handler\n");
+ err = register_oom_notifier(&oom_nb);
+ if (err) printk(KERN_ERR "Error installing oom_panic handler\n");
+ return err;
+}
+
+static void __exit exit_oom_panic(void)
+{
+ unregister_oom_notifier(&oom_nb);
+}
+
+module_init(init_oom_panic);
+module_exit(exit_oom_panic);
+MODULE_LICENSE("GPL");
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [RFC] Enabling other oom schemes
2003-09-12 2:19 [RFC] Enabling other oom schemes Rusty Lynch
@ 2003-09-12 4:18 ` Rahul Karnik
2003-09-12 4:31 ` Chris Friesen
2003-09-12 4:47 ` Robert Love
2003-09-13 17:48 ` Jamie Lokier
1 sibling, 2 replies; 13+ messages in thread
From: Rahul Karnik @ 2003-09-12 4:18 UTC (permalink / raw)
To: rusty; +Cc: riel, linux-mm, linux-kernel
Rusty Lynch wrote:
> The patch below uses a notifier list for other components to register
> to be called when an out of memory condition occurs.
How does this interact with the overcommit handling? Doesn't strict
overcommit also not oom, but rather return a memory allocation error?
Could we not add another overcommit mode where oom conditions cause a
kernel panic?
Thanks,
Rahul
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-12 4:18 ` Rahul Karnik
@ 2003-09-12 4:31 ` Chris Friesen
2003-09-12 4:40 ` Rahul Karnik
` (2 more replies)
2003-09-12 4:47 ` Robert Love
1 sibling, 3 replies; 13+ messages in thread
From: Chris Friesen @ 2003-09-12 4:31 UTC (permalink / raw)
To: Rahul Karnik; +Cc: rusty, riel, linux-mm, linux-kernel
Rahul Karnik wrote:
> Rusty Lynch wrote:
>
>> The patch below uses a notifier list for other components to register
>> to be called when an out of memory condition occurs.
>
>
> How does this interact with the overcommit handling? Doesn't strict
> overcommit also not oom, but rather return a memory allocation error?
> Could we not add another overcommit mode where oom conditions cause a
> kernel panic?
If you have real, true strict overcommit, then it can cause you to have
errors much earlier than expected.
Imagine a process that consumes 51% of memory. With strict overcommit,
that process cannot fork() since there is not enough memory.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [RFC] Enabling other oom schemes
2003-09-12 4:31 ` Chris Friesen
@ 2003-09-12 4:40 ` Rahul Karnik
2003-09-12 4:48 ` Robert Love
2003-09-12 11:18 ` Helge Hafting
2003-09-12 14:30 ` M. Edward Borasky
2 siblings, 1 reply; 13+ messages in thread
From: Rahul Karnik @ 2003-09-12 4:40 UTC (permalink / raw)
To: Chris Friesen; +Cc: rusty, linux-mm, linux-kernel
Chris Friesen wrote:
> If you have real, true strict overcommit, then it can cause you to have
> errors much earlier than expected.
I was referring to the "strict overcommit" mode described in
Documentation/vm/overcommit-accounting. To me, it sounded like it was
describing modes that were alternatives to the proposed kernel panic on
oom, and I was merely suggesting we use the same /proc/sys/vm method to
specify oom behavior (maybe a string rather than numeric codes in case
we have several such options in the future). Apologies if this is not
related to what Rusty is talking about.
Thanks,
Rahul
--
Rahul Karnik
rahul@genebrew.com
http://www.genebrew.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-12 4:40 ` Rahul Karnik
@ 2003-09-12 4:48 ` Robert Love
0 siblings, 0 replies; 13+ messages in thread
From: Robert Love @ 2003-09-12 4:48 UTC (permalink / raw)
To: Rahul Karnik; +Cc: Chris Friesen, rusty, linux-mm, linux-kernel
On Fri, 2003-09-12 at 00:40, Rahul Karnik wrote:
> I was referring to the "strict overcommit" mode described in
> Documentation/vm/overcommit-accounting.
Right. What Chris said is true. Strict overcommit has limitations, and
hence it is not the default.
> To me, it sounded like it was
> describing modes that were alternatives to the proposed kernel panic on
> oom, and I was merely suggesting we use the same /proc/sys/vm method to
> specify oom behavior (maybe a string rather than numeric codes in case
> we have several such options in the future). Apologies if this is not
> related to what Rusty is talking about.
I don't think the two are related. You can have both, separately or
together.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-12 4:31 ` Chris Friesen
2003-09-12 4:40 ` Rahul Karnik
@ 2003-09-12 11:18 ` Helge Hafting
2003-09-12 14:07 ` Chris Friesen
2003-09-12 14:30 ` M. Edward Borasky
2 siblings, 1 reply; 13+ messages in thread
From: Helge Hafting @ 2003-09-12 11:18 UTC (permalink / raw)
To: Chris Friesen; +Cc: Rahul Karnik, rusty, riel, linux-mm, linux-kernel
On Fri, Sep 12, 2003 at 12:31:27AM -0400, Chris Friesen wrote:
> Rahul Karnik wrote:
> >Rusty Lynch wrote:
> >
> >>The patch below uses a notifier list for other components to register
> >>to be called when an out of memory condition occurs.
> >
> >
> >How does this interact with the overcommit handling? Doesn't strict
> >overcommit also not oom, but rather return a memory allocation error?
> >Could we not add another overcommit mode where oom conditions cause a
> >kernel panic?
>
> If you have real, true strict overcommit, then it can cause you to have
> errors much earlier than expected.
>
> Imagine a process that consumes 51% of memory. With strict overcommit,
> that process cannot fork() since there is not enough memory.
Note that this "memory" is RAM+swap. So you can avoid allocation
failure by giving your strict overcommit box much more swap space.
The allocations will be backed by swap, this won't slow the machine
down at all because it isn't used normally. Or to put it another
way - you'll use that extra swap only in those situations where
you otherwise get allocation failure or OOM killing.
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-12 11:18 ` Helge Hafting
@ 2003-09-12 14:07 ` Chris Friesen
0 siblings, 0 replies; 13+ messages in thread
From: Chris Friesen @ 2003-09-12 14:07 UTC (permalink / raw)
To: Helge Hafting; +Cc: Rahul Karnik, rusty, riel, linux-mm, linux-kernel
Helge Hafting wrote:
> On Fri, Sep 12, 2003 at 12:31:27AM -0400, Chris Friesen wrote:
> Note that this "memory" is RAM+swap. So you can avoid allocation
> failure by giving your strict overcommit box much more swap space.
This works great for the desktop, doesn't work so well when you don't
have any swap--as is the case for most embedded apps that would like
stricter overcommit.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [RFC] Enabling other oom schemes
2003-09-12 4:31 ` Chris Friesen
2003-09-12 4:40 ` Rahul Karnik
2003-09-12 11:18 ` Helge Hafting
@ 2003-09-12 14:30 ` M. Edward Borasky
2 siblings, 0 replies; 13+ messages in thread
From: M. Edward Borasky @ 2003-09-12 14:30 UTC (permalink / raw)
To: linux-mm
> -----Original Message-----
> From: owner-linux-mm@kvack.org
> [mailto:owner-linux-mm@kvack.org] On Behalf Of Chris Friesen
> Sent: Thursday, September 11, 2003 9:31 PM
> To: Rahul Karnik
> Cc: rusty@linux.co.intel.com; riel@conectiva.com.br;
> linux-mm@kvack.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC] Enabling other oom schemes
[snip]
> Imagine a process that consumes 51% of memory. With strict
> overcommit,
> that process cannot fork() since there is not enough memory.
Let's put some quantification on this thought experiment. Imagine a 4
gigabyte "timesharing" server with hundreds of users. Each user has a few
processes consuming perhaps 5 - 50 megabytes of virtual address space. In
this context, a single userspace process consuming 51 percent of real memory
-- a tad over 2 gigabytes -- not only cannot fork *itself*, but also most
likely is interfering with the operations of the other users. Most likely
hundreds of voices would be raised in protest against the 2 gigabyte
process, and, if Linux didn't wipe it off the face of the Earth, the
managers of the server would. At the very least it would be "suggested" to
the 2 gigabyte process owner that a separate machine be procured to run it,
or another 2 gigabytes would be purchased to accommodate it in the same
server.
Now, imagine that 4 gigabyte server has, instead of a 2+ gigabyte userspace
process, 2+ gigabytes of RAM tied up in page cache. The effect on the
hundreds of users is the same, but there's a difference: because the
*kernel* owns the page cache, and not a "mere userspace process", the OOM
killer won't deal with it. And the server managers may not be able to deal
with it either, since we don't expect them to be authorized to re-code the
kernel or change the Linux memory management philosophy.
--
M. Edward (Ed) Borasky
mailto:znmeb@borasky-research.net
http://www.borasky-research.net/RunYourOwnBrain/
"Suppose that tonight, while you sleep, a miracle happens - you wake up
tomorrow with what you have longed for! How will you discover that a miracle
happened? How will your loved ones? What will be different? What will you
notice? What do you need to explode into tomorrow with grace, power, love,
passion and confidence?" -- L. Michael Hall, PhD
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-12 4:18 ` Rahul Karnik
2003-09-12 4:31 ` Chris Friesen
@ 2003-09-12 4:47 ` Robert Love
1 sibling, 0 replies; 13+ messages in thread
From: Robert Love @ 2003-09-12 4:47 UTC (permalink / raw)
To: Rahul Karnik; +Cc: rusty, riel, linux-mm, linux-kernel
On Fri, 2003-09-12 at 00:18, Rahul Karnik wrote:
> How does this interact with the overcommit handling? Doesn't strict
> overcommit also not oom, but rather return a memory allocation error?
Right. Technically, with strict overcommit and a sufficient overcommit
ratio, you cannot OOM.
But this is for people who do have a chance of OOM, because strict
overcommit is not for everyone.
> Could we not add another overcommit mode where oom conditions cause a
> kernel panic?
The two are unrelated.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-12 2:19 [RFC] Enabling other oom schemes Rusty Lynch
2003-09-12 4:18 ` Rahul Karnik
@ 2003-09-13 17:48 ` Jamie Lokier
2003-09-13 20:52 ` Robert Love
1 sibling, 1 reply; 13+ messages in thread
From: Jamie Lokier @ 2003-09-13 17:48 UTC (permalink / raw)
To: rusty; +Cc: riel, linux-mm, linux-kernel
Rusty Lynch wrote:
> Over the years I have encountered various usage needs where the standard
> oom_kill.c version of memory recovery was not the most ideal approach.
> For example, some times it is better to just restart the system and
> let a front end load balancer hand off the server load to another system.
> Sometimes it might be worth the effort to write a very solution specific
> oom handler.
I would like to reboot a remote server when it is overloaded, or a
deterministic policy that kills off services starting with those
deemed less essential, but what is the best way to detect overload?
IMHO, the server is overloaded when tasks are no longer responding in
a reasonable time, due to excessive paging.
It isn't feasible to work out in advance how much swap this
corresponds to, because it depends how much swap is used by "idle"
pages, and how much is likely to be filled with working sets.
Too much swap, and it won't OOM even while it becomes totally
unresponsive for days and needs a manual reset. Too little swap, and
valuable RAM is being wasted.
What I'd really like is some way to observe task response times,
and when they become too slow due to excessive paging, trigger the OOM
policy whatever it is.
Also, when the OOM condition is triggered I'd like the system to
reboot, but first try for a short while to unmount filesystems cleanly.
Any chance of those things?
Thanks in advance :)
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-13 17:48 ` Jamie Lokier
@ 2003-09-13 20:52 ` Robert Love
2003-09-14 5:28 ` Chris Friesen
2003-09-15 0:11 ` Mike S
0 siblings, 2 replies; 13+ messages in thread
From: Robert Love @ 2003-09-13 20:52 UTC (permalink / raw)
To: Jamie Lokier; +Cc: rusty, riel, linux-mm, linux-kernel
On Sat, 2003-09-13 at 13:48, Jamie Lokier wrote:
> Also, when the OOM condition is triggered I'd like the system to
> reboot, but first try for a short while to unmount filesystems cleanly.
>
> Any chance of those things?
I like all of these ideas.
One thing to keep in mind is that during a real OOM condition, we cannot
allocate _any_ memory. None. Zilch.
And that makes some things very hard. When we start getting into things
such as complicated policies that kill nonessential services first, et
cetera... there comes a time where a lot of communication is needed
(probably with user-space). Hard to do that with no memory.
I do like all of this, however, and want to see some different OOM
killers.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-13 20:52 ` Robert Love
@ 2003-09-14 5:28 ` Chris Friesen
2003-09-15 0:11 ` Mike S
1 sibling, 0 replies; 13+ messages in thread
From: Chris Friesen @ 2003-09-14 5:28 UTC (permalink / raw)
To: Robert Love; +Cc: Jamie Lokier, rusty, riel, linux-mm, linux-kernel
Robert Love wrote:
> On Sat, 2003-09-13 at 13:48, Jamie Lokier wrote:
>
>
>>Also, when the OOM condition is triggered I'd like the system to
>>reboot, but first try for a short while to unmount filesystems cleanly.
>>
>>Any chance of those things?
<snip>
> I do like all of this, however, and want to see some different OOM
> killers.
One thing that we've done, and that others may find useful, is to allow
processes to become immune to the oom-killer as long as they stay under
a certain amount of memory allocated.
We added a syscall that specifies a certain number of pages of memory.
As long as the process' memory utilization remains under that amount,
the oom-killer will not kill it.
In our case we are on a mostly-embedded system, and have a pretty good
idea what will be running. This lets us engineer the critical apps to
be immune, while still allowing memory to be freed up by killing
non-critical applications.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Enabling other oom schemes
2003-09-13 20:52 ` Robert Love
2003-09-14 5:28 ` Chris Friesen
@ 2003-09-15 0:11 ` Mike S
1 sibling, 0 replies; 13+ messages in thread
From: Mike S @ 2003-09-15 0:11 UTC (permalink / raw)
To: Robert Love; +Cc: Jamie Lokier, rusty, riel, linux-mm, linux-kernel
Robert Love wrote:
> One thing to keep in mind is that during a real OOM condition, we cannot
> allocate _any_ memory. None. Zilch.
>
> And that makes some things very hard. When we start getting into things
> such as complicated policies that kill nonessential services first, et
> cetera... there comes a time where a lot of communication is needed
> (probably with user-space). Hard to do that with no memory.
A possible, but not very efficient workaround is to reserve memory or
swap just for this condition. Obviously this limits available memory for
other process (which in theory could cause an OOM in the first place)
and would be wasted most of the time. Possibly this reserved memory
would be used as a filesystem read cache until OOM, when it would be
cleared out and used for whatever.
--
~Mike
wickedchicken@plasticpenguins.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-09-15 0:11 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-12 2:19 [RFC] Enabling other oom schemes Rusty Lynch
2003-09-12 4:18 ` Rahul Karnik
2003-09-12 4:31 ` Chris Friesen
2003-09-12 4:40 ` Rahul Karnik
2003-09-12 4:48 ` Robert Love
2003-09-12 11:18 ` Helge Hafting
2003-09-12 14:07 ` Chris Friesen
2003-09-12 14:30 ` M. Edward Borasky
2003-09-12 4:47 ` Robert Love
2003-09-13 17:48 ` Jamie Lokier
2003-09-13 20:52 ` Robert Love
2003-09-14 5:28 ` Chris Friesen
2003-09-15 0:11 ` Mike S
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox