oom notifications via /dev/oom_notify

Hi,

Following patch creates a /dev/oom_notify device which applications can select()/poll() to get informed of memory pressure.

The basic idea here is that applications can be part of the memory reclaim process. The notification is loosely defined as "please free some small percentage of your memory".

There is no easy way of finding whether the system is approaching a state where swapping is required in the reclaim paths, so a defensive approach is taken by using a timer with 1Hz frequency which verifies whether swapping has occurred.

For scenarios which require a "severe pressure notification" (please read Nokia's implementation at http://www.linuxjournal.com/article/8502 for more details), I believe the best solution is to create a separate /dev/oom_notify_critical device to avoid complication of the main device code paths. Take into account that such notification needs careful synchronization with the OOM killer.

Comments please...

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/drivers/char/mem.c linux-2.6/drivers/char/mem.c

drivers/char/mem.c +6 -0

@@ -34,6 +34,8 @@
 # include <linux/efi.h>
 #endif
 
+extern struct file_operations oom_notify_fops;
+
 /*
  * Architectures vary in how they handle caching for addresses
  * outside of main memory.

@@ -854,6 +856,9 @@
 			filp->f_op = &oldmem_fops;
 			break;
 #endif
+		case 13:
+			filp->f_op = &oom_notify_fops;
+			break;
 		default:
 			return -ENXIO;
 	}

@@ -886,6 +891,7 @@
 #ifdef CONFIG_CRASH_DUMP
 	{12,"oldmem",    S_IRUSR | S_IWUSR | S_IRGRP, &oldmem_fops},
 #endif
+	{13,"oom_notify", S_IRUGO, &oom_notify_fops},
 };
 
 static struct class *mem_class;

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/include/linux/vmstat.h linux-2.6/include/linux/vmstat.h

include/linux/vmstat.h +1 -0

@@ -80,6 +80,7 @@
 }
 
 extern void all_vm_events(unsigned long *);
+extern unsigned int sum_vm_event(int);
 #ifdef CONFIG_HOTPLUG
 extern void vm_events_fold_cpu(int cpu);
 #else

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/mm/Kconfig linux-2.6/mm/Kconfig

mm/Kconfig +7 -0

@@ -170,6 +170,13 @@
 	  example on NUMA systems to put pages nearer to the processors accessing
 	  the page.
 
+config OOM_NOTIFY
+	bool "Memory notification"
+	def_bool n
+	help
+	  This option allows the kernel to notify applications of memory 
+	  shortage.
+
 config RESOURCES_64BIT
 	bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT && EXPERIMENTAL)
 	default 64BIT

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/mm/Makefile linux-2.6/mm/Makefile

mm/Makefile +1 -0

@@ -30,4 +30,5 @@
 obj-$(CONFIG_MIGRATION) += migrate.o
 obj-$(CONFIG_SMP) += allocpercpu.o
 obj-$(CONFIG_QUICKLIST) += quicklist.o
+obj-$(CONFIG_OOM_NOTIFY) += oom_notify.o
 

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/mm/oom_notify.c linux-2.6/mm/oom_notify.c

mm/oom_notify.c +23 -0

@@ -0,0 +1,96 @@
+/*
+ * Notify applications of memory pressure via /dev/oom_notify
+ */
+
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/wait.h>
+#include <linux/poll.h>
+#include <linux/timer.h>
+#include <linux/spinlock.h>
+#include <linux/vmstat.h>
+
+static int oom_notify_users = 0;
+static bool oom_notify_status = 0;
+static unsigned int prev_swapped_pages = 0;
+
+static void oom_check_fn(unsigned long);
+
+DECLARE_WAIT_QUEUE_HEAD(oom_wait);
+DEFINE_SPINLOCK(oom_notify_lock);
+static struct timer_list oom_check_timer =
+		TIMER_INITIALIZER(oom_check_fn, 0, 0);
+

mm/oom_notify.c +38 -0

+		mod_timer(&oom_check_timer, oom_check_timer.expires);
+	}
+	oom_notify_users++;
+	spin_unlock(&oom_notify_lock);
+
+	return 0;
+}
+
+static int oom_notify_release(struct inode *inode, struct file *file)
+{
+	spin_lock(&oom_notify_lock);
+	oom_notify_users--;
+	if (!oom_notify_users) {
+		del_timer(&oom_check_timer);
+		oom_notify_status = 0;
+	}
+	spin_unlock(&oom_notify_lock);
+	return 0;
+}
+
+static unsigned int oom_notify_poll(struct file *file, poll_table *wait)
+{
+	unsigned int val = 0;
+	struct zone *zone;
+	int cz_idx = zone_idx(NODE_DATA(nid)->node_zonelists->zones[0]);
+
+	poll_wait(file, &oom_wait, wait);
+
+	if (oom_notify_status)
+		val = POLLIN;
+
+	for_each_zone(zone) {
+		if (!populated_zone(zone))
+			continue;	
+		if (!zone_watermark_ok(zone, 0, zone->pages_low, cz_idx, 0)) {
+			val = POLLIN;
+			break;
+		}

mm/oom_notify.c +1 -0

+EXPORT_SYMBOL(oom_notify_fops);

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/mm/vmstat.c linux-2.6/mm/vmstat.c

mm/vmstat.c +11 -0

@@ -52,6 +52,28 @@
 }
 EXPORT_SYMBOL_GPL(all_vm_events);
 
+unsigned int sum_vm_event(int vm_event)
+{
+	int cpu = 0;
+	int i;
+	unsigned int ret = 0;
+	cpumask_t *cpumask = &cpu_online_map;
+
+	cpu = first_cpu(*cpumask);
+	while (cpu < NR_CPUS) {
+		struct vm_event_state *this = &per_cpu(vm_event_states, cpu);
+

mm/vmstat.c +1 -0

+
 #ifdef CONFIG_HOTPLUG
 /*
  * Fold the foreign cpu events into our own.

diff -Nur --exclude-from=linux-2.6/Documentation/dontdiff linux-2.6.orig/include/linux/vmstat.h linux-2.6/include/linux/vmstat.h

include/linux/vmstat.h +1 -1

@@ -80,6 +80,7 @@
 }
 
 extern void all_vm_events(unsigned long *);
+extern unsigned int sum_vm_event(int);
 #ifdef CONFIG_HOTPLUG
 extern void vm_events_fold_cpu(int cpu);
 #else
 
--

To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

mm/oom_notify.c line 33

Quoted 10 lines

mm/oom_notify.c +10 -0

+void oom_check_fn(unsigned long unused)
+{
+	bool wake = 0;
+	unsigned int swapped_pages;
+
+	swapped_pages = sum_vm_event(PSWPOUT);
+	if (swapped_pages > prev_swapped_pages)
+		wake = 1;
+	prev_swapped_pages = swapped_pages;
+

Two comments

1. So this is a rate growth function and continues to wake up tasks as long as the rate of swapout keeps growing?"

2. How will this function work in the absence of swap? Does this feature work in the absence of swap?

mm/oom_notify.c line 43

Quoted 10 lines

mm/oom_notify.c +10 -0

+	oom_notify_status = wake;
+
+	if (wake)
+		wake_up_all(&oom_wait);
+
+	return;
+}
+
+static int oom_notify_open(struct inode *inode, struct file *file)
+{

Should we check current->oomkilladj before allowing open to proceed?

mm/oom_notify.c line 47

Quoted 4 lines

mm/oom_notify.c +4 -0

+	spin_lock(&oom_notify_lock);
+	if (!oom_notify_users) {
+		oom_notify_status = 0;
+		oom_check_timer.expires = jiffies + msecs_to_jiffies(1000);

A more meaningful name for 1000, here please?

Quoted 44 lines

mm/oom_notify.c +44 -0

+		mod_timer(&oom_check_timer, oom_check_timer.expires);
+	}
+	oom_notify_users++;
+	spin_unlock(&oom_notify_lock);
+
+	return 0;
+}
+
+static int oom_notify_release(struct inode *inode, struct file *file)
+{
+	spin_lock(&oom_notify_lock);
+	oom_notify_users--;
+	if (!oom_notify_users) {
+		del_timer(&oom_check_timer);
+		oom_notify_status = 0;
+	}
+	spin_unlock(&oom_notify_lock);
+	return 0;
+}
+
+static unsigned int oom_notify_poll(struct file *file, poll_table *wait)
+{
+	unsigned int val = 0;
+	struct zone *zone;
+	int cz_idx = zone_idx(NODE_DATA(nid)->node_zonelists->zones[0]);
+
+	poll_wait(file, &oom_wait, wait);
+
+	if (oom_notify_status)
+		val = POLLIN;
+
+	for_each_zone(zone) {
+		if (!populated_zone(zone))
+			continue;	
+		if (!zone_watermark_ok(zone, 0, zone->pages_low, cz_idx, 0)) {
+			val = POLLIN;
+			break;
+		}
+	}
+
+	return val;
+}
+
+struct file_operations oom_notify_fops = {

mm/oom_notify.c line 95

Quoted 4 lines

mm/oom_notify.c +4 -0

+	.open = oom_notify_open,
+	.release = oom_notify_release,
+	.poll = oom_notify_poll,
+};

Can we also implement a oom_notify_read() function, so that a read on /dev/oom_notify will give the reason for returning on select on /dev/oom_notify.

The basic idea here is that applications can be part of the memory reclaim process. The notification is loosely defined as "please free some small percentage of your memory".

There is no easy way of finding whether the system is approaching a state where swapping is required in the reclaim paths, so a defensive approach is taken by using a timer with 1Hz frequency which verifies whether swapping has occurred.

mm/oom_notify.c +7 -0

+void oom_check_fn(unsigned long unused)
+{
+	bool wake = 0;
+	unsigned int swapped_pages;
+
+	swapped_pages = sum_vm_event(PSWPOUT);
+	if (swapped_pages > prev_swapped_pages)

Hi,

Following patch creates a /dev/oom_notify device which applications can select()/poll() to get informed of memory pressure.

The basic idea here is that applications can be part of the memory reclaim process. The notification is loosely defined as "please free some small percentage of your memory".

There is no easy way of finding whether the system is approaching a state where swapping is required in the reclaim paths, so a defensive approach is taken by using a timer with 1Hz frequency which verifies whether swapping has occurred.

For scenarios which require a "severe pressure notification" (please read Nokia's implementation at http://www.linuxjournal.com/article/8502 for more details), I believe the best solution is to create a separate /dev/oom_notify_critical device to avoid complication of the main device code paths. Take into account that such notification needs careful synchronization with the OOM killer.

Comments please...

Quoted 1 line

Comments please...

changes:
- rearm timer (!)
- wake up one thread instead of all in swapout detection
- msecs_to_jiffies(1000) -> HZ

Quoted 6 lines · On Tue, 30 Oct 2007 17:07:43 -0400 Marcelo Tosatti <[email protected]> wrote:

Quoted 1 line

Comments please...

changes:
- rearm timer (!)
- wake up one thread instead of all in swapout detection
- msecs_to_jiffies(1000) -> HZ

Would it be an idea to use round_jiffies() ?

drivers/char/mem.c line 861

Quoted 3 lines · Marcelo Tosatti

drivers/char/mem.c +3 -0

+		case 13:
+			filp->f_op = &oom_notify_fops;
+			break;

Don't forget to add this to Documentation/devices.txt

Quoted 6 lines

mm/vmstat.c +6 -0

+	while (cpu < NR_CPUS) {
+		struct vm_event_state *this = &per_cpu(vm_event_states, cpu);
+
+		cpu = next_cpu(cpu, *cpumask);
+
+		if (cpu < NR_CPUS)

mm/vmstat.c line 74

Quoted 6 lines

mm/vmstat.c +6 -0

+			prefetch(&per_cpu(vm_event_states, cpu));
+
+		ret += this->event[vm_event];
+	}
+	return ret;
+}

Is the prefetching worth it?

Hi,

Following patch creates a /dev/oom_notify device which applications can select()/poll() to get informed of memory pressure.

The basic idea here is that applications can be part of the memory reclaim process. The notification is loosely defined as "please free some small percentage of your memory".

There is no easy way of finding whether the system is approaching a state where swapping is required in the reclaim paths, so a defensive approach is taken by using a timer with 1Hz frequency which verifies whether swapping has occurred.

For scenarios which require a "severe pressure notification" (please read Nokia's implementation at http://www.linuxjournal.com/article/8502 for more details), I believe the best solution is to create a separate /dev/oom_notify_critical device to avoid complication of the main device code paths. Take into account that such notification needs careful synchronization with the OOM killer.

Comments please...

Interesting.. Our database folks wanted some kind of notification when there is memory pressure and we are about to kill the biggest consumer (in most cases, the most useful application :(). What actually they want is a way to get notified, so that they can shrink their memory footprint in response. Just notifying before OOM may not help, since they don't have time to react. How does this notification help ? Are they supposed to monitor swapping activity and decide ?

Quoted 8 lines · On Tue, 30 Oct 2007 13:59:28 -0800 Badari Pulavarty <[email protected]> wrote:

Interesting.. Our database folks wanted some kind of notification when there is memory pressure and we are about to kill the biggest consumer (in most cases, the most useful application :(). What actually they want is a way to get notified, so that they can shrink their memory footprint in response. Just notifying before OOM may not help, since they don't have time to react. How does this notification help ? Are they supposed to monitor swapping activity and decide ?

Marcelo's code monitors swapping activity and will let userspace programs (that poll/select the device node) know when they should shrink their memory footprint.

This is not "OOM" in the sense of "no more memory or swap", but in the sense of "we're low on memory - if you don't free something we'll slow you down by swapping stuff".

Quoted 13 lines · Rik van Riel

Quoted 8 lines · On Tue, 30 Oct 2007 13:59:28 -0800 Badari Pulavarty <[email protected]> wrote:

Interesting.. Our database folks wanted some kind of notification when there is memory pressure and we are about to kill the biggest consumer (in most cases, the most useful application :(). What actually they want is a way to get notified, so that they can shrink their memory footprint in response. Just notifying before OOM may not help, since they don't have time to react. How does this notification help ? Are they supposed to monitor swapping activity and decide ?

Quoted 9 lines

Marcelo's code monitors swapping activity and will let userspace programs (that poll/select the device node) know when they should shrink their memory footprint.

This is not "OOM" in the sense of "no more memory or swap", but in the sense of "we're low on memory - if you don't free something we'll slow you down by swapping stuff".

I think having this kind of OOM notification is a decent start. But any applications that
wants to know notifications, would be more interested if kernel is swapping out any of
its data,

Quoted 23 lines · On Tue, 30 Oct 2007 21:17:32 -0700 Badari <[email protected]> wrote:

Quoted 13 lines · Rik van Riel

Quoted 8 lines · On Tue, 30 Oct 2007 13:59:28 -0800 Badari Pulavarty <[email protected]> wrote:

Interesting.. Our database folks wanted some kind of notification when there is memory pressure and we are about to kill the biggest consumer (in most cases, the most useful application :(). What actually they want is a way to get notified, so that they can shrink their memory footprint in response. Just notifying before OOM may not help, since they don't have time to react. How does this notification help ? Are they supposed to monitor swapping activity and decide ?

Quoted 9 lines

Marcelo's code monitors swapping activity and will let userspace programs (that poll/select the device node) know when they should shrink their memory footprint.

This is not "OOM" in the sense of "no more memory or swap", but in the sense of "we're low on memory - if you don't free something we'll slow you down by swapping stuff".

Quoted 5 lines

I think having this kind of OOM notification is a decent start. But any applications that
wants to know notifications, would be more interested if kernel is swapping out any of
its data,

Well, if the scheme is implemented "right", then what you describe will never happen because programs will have freed their excess memory already before any swapping happens.

Quoted 3 lines

Well, if the scheme is implemented "right", then what you describe will never happen because programs will have freed their excess memory already before any swapping happens.

Hmm.. Most cases, application doesn't care about swapping activity of the kernel - unless its something to do with one of its own processes/threads. So having notifications per-process/app/cgroup is what they are looking for.

But again, how they would react to the notification is an interesting thing. If they really act nice and free up stuff they don't need or read more crap and cause more swapping :(

Quoted 13 lines · Rik van Riel

Quoted 8 lines · On Tue, 30 Oct 2007 13:59:28 -0800 Badari Pulavarty <[email protected]> wrote:

Interesting.. Our database folks wanted some kind of notification when there is memory pressure and we are about to kill the biggest consumer (in most cases, the most useful application :(). What actually they want is a way to get notified, so that they can shrink their memory footprint in response. Just notifying before OOM may not help, since they don't have time to react. How does this notification help ? Are they supposed to monitor swapping activity and decide ?

Quoted 9 lines

Marcelo's code monitors swapping activity and will let userspace programs (that poll/select the device node) know when they should shrink their memory footprint.

This is not "OOM" in the sense of "no more memory or swap", but in the sense of "we're low on memory - if you don't free something we'll slow you down by swapping stuff".

I think having this kind of OOM notification is a decent start. But any applications that
wants to know notifications, would be more interested if kernel is swapping out any of
its data, than overall system swapping events. I guess, making it per-process or per-cgroup
may be logical extension. I am not sure if its really practical , though...

Thanks,
Badari