Automatice kernel tunables (AKT)

[PATCH 01/06]

Defines the auto_tune structure: this is the structure that contains the information needed by the adjustment routine for a given tunable. Also defines the registration routines.

The fork kernel component defines a tunable structure for the threads-max tunable and registers it.

Signed-off-by Nadia Derbey <[email protected]>

---
 Documentation/00-INDEX      |    2 
 Documentation/auto_tune.txt |  333 ++++++++++++++++++++++++++++++++++++++++++++
 fs/Kconfig                  |    2 
 include/linux/akt.h         |  186 ++++++++++++++++++++++++
 include/linux/akt_ops.h     |  186 ++++++++++++++++++++++++
 init/main.c                 |    2 
 kernel/Makefile             |    1 
 kernel/autotune/Kconfig     |   30 +++
 kernel/autotune/Makefile    |    7 
 kernel/autotune/akt.c       |  123 ++++++++++++++++
 kernel/fork.c               |   18 ++
 11 files changed, 890 insertions(+)

Index: linux-2.6.20-rc4/Documentation/auto_tune.txt
===================================================================

Documentation/auto_tune.txt new file +7 -0

@@ -0,0 +1,333 @@
+			Automatic Kernel Tunables
+                        =========================
+
+		   Nadia Derbey ([email protected])
+
+
+

Documentation/auto_tune.txt new file +5 -0

+- a structure is declared and filled by the kernel subsystem for the
+registered tunable
+- that tunable structure is registered into sysfs
+
+Registration should be done during the kernel subsystem initialization step.

Documentation/auto_tune.txt new file +7 -0

+Any kernel subsystem that has registered a tunable should call
+auto_tune_func() as follows:
+
++-------------------------+--------------------------------------------+
+| Step                    | Routine to call                            |
++-------------------------+--------------------------------------------+
+| Declaration phase       | DEFINE_TUNABLE(name, values...);           |

+. call the routine stored in tunable->auto_tune

Documentation/auto_tune.txt new file +24 -0

+
+
+The effect of the default automatic tuning routine is the following:
+
+           +----------------------------------------------------------------+
+           |                 Tunable automatically adjustable               |
+           +---------------+------------------------------------------------+
+           |      NO       |                      YES                       |
++----------+---------------+------------------------------------------------+
+| AKT_UP   | No effect     | If the tunable value exceeds the specified     |
+|          |               | threshold, that value is increased up to a     |
+|          |               | maximum value.                                 |
+|          |               | The maximum value is specified during the      |
+|          |               | tunable declaration and can be changed at any  |
+|          |               | time through sysfs                             |
++----------+---------------+------------------------------------------------+
+| AKT_DOWN | No effect     | If the tunable value falls under the specified |
+|          |               | threshold, that value is decreased down to a   |
+|          |               | minimum value.                                 |
+|          |               | The minimum value is specified during the      |
+|          |               | tunable declaration and can be changed at any  |
+|          |               | time through sysfs                             |
++----------+---------------+------------------------------------------------+
+

+1.1 for the detailed description):

+- threshold
+- key
+- min
+- max
+- tunable
+- checked

Documentation/auto_tune.txt new file +10 -0

+
+When this routine is entered, it does the following:
+1. <*checked> is compared to <*tunable> * threshold
+2. if <*checked> is greater, <*tunable> is set to:
+	<*tunable> + (<*tunable> * (100 - threshold) / 100)
+
+
+
+1.6) akt and sysfs:
+

Documentation/auto_tune.txt new file +3 -0

+
+1.7) tunables that are namespace dependent
+

Documentation/auto_tune.txt new file +4 -0

+
+1.7.2) Initializing the tunable structure
+
+Then the tunable structure should be initialized by calling the following

Documentation/auto_tune.txt new file +3 -0

+
+1.7.3) Registering the tunable structure
+

++-----------+---------------+-------------------+----------------------------+
+| attribute | default value | how to set it | effect |
++-----------+---------------+-------------------+----------------------------+

+| autotune  | 0             | echo 1 > autotune | makes the tunable automatic|
+|           |               | echo 0 > autotune | makes the tunable manual   |
++-----------+---------------+-------------------+----------------------------+
+| max       | max value set | echo <M> > max    | sets the tunable max value |
+|           | during tunable|                   | to <M>                     |
+|           | definition    |                   |                            |
++-----------+---------------+-------------------+----------------------------+
+| min       | min value set | echo <m> > min    | sets the tunable min value |
+|           | during tunable|                   | to <m>                     |
+|           | definition    |                   |                            |

++-----------+---------------+-------------------+----------------------------+
+
Index: linux-2.6.20-rc4/fs/Kconfig
===================================================================

fs/Kconfig +0 -0

 config PROC_VMCORE
         bool "/proc/vmcore support (EXPERIMENTAL)"
         depends on PROC_FS && EXPERIMENTAL && CRASH_DUMP

Index: linux-2.6.20-rc4/include/linux/akt.h
===================================================================

include/linux/akt.h new file +17 -0

@@ -0,0 +1,186 @@
+
+#ifndef AKT_H
+#define AKT_H
+
+#include <linux/types.h>
+#include <linux/kobject.h>
+
+/*
+ * First parameter passed to the adjustment routine
+ */
+#define AKT_UP   0   /* adjustment "up" */
+#define AKT_DOWN 1   /* adjustment "down" */
+
+
+struct auto_tune {
+	spinlock_t tunable_lck; /* serializes access to the stucture fields */
+	auto_tune_fn auto_tune; /* auto tuning routine registered by the */

include/linux/akt.h new file +12 -0

+	char threshold;	/* threshold to enable the adjustment expressed as */
+			/* a %age */
+	struct typed_value min;	/* min value the tunable can ever reach */
+				/* and associated show / store routines) */
+	struct typed_value max;	/* max value the tunable can ever reach */
+				/* and associated show / store routines) */
+	void *tunable;	/* address of the tunable to adjust */
+	void *checked;	/* address of the variable that is controlled by */
+			/* the tunable. This is the calling subsystem's */
+			/* object counter */
+};
+

+#endif /* AKT_H */

Index: linux-2.6.20-rc4/kernel/autotune/akt.c
===================================================================

kernel/autotune/akt.c new file +14 -0

@@ -0,0 +1,123 @@
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/akt.h>
+
+
+
+	Too Much Whitespace.  :)
+
+
+
+/*
+ * FUNCTION:    Inserts a tunable structure into sysfs
+ *              This routine serves also as a checker for the tunable

kernel/autotune/akt.c new file +48 -0

+		return -EINVAL;
+	}
+
+	if (tun->tunable == NULL) {
+		printk(KERN_ERR "\tBad tunable pointer (NULL)\n");
+		return -EINVAL;
+	}
+
+	if (tun->checked == NULL) {
+		printk(KERN_ERR "\tBad checked value pointer (NULL)\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Check the min / max value
+	 */
+	if (tun->check_parms(tun)) {
+		printk(KERN_ERR "\tBad min / max values\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+
+/*
+ * FUNCTION:    Removes a tunable structure from sysfs.
+ *              This routine is called by any kernel subsystem that doesn't
+ *              need the akt services anymore
+ *
+ * NOTE:  reg_tun should point to a previously registered tunable
+ *
+ * RETURN VALUE: 0: successful
+ *               <0 if failure
+ */
+int unregister_tunable(struct auto_tune *reg_tun)
+{
+	if (reg_tun == NULL) {
+		printk(KERN_ERR "\tBad tunable address (NULL)\n");
+		return -EINVAL;
+	}
+
+	spin_lock(&reg_tun->tunable_lck);
+
+	BUG_ON(!is_tunable_registered(reg_tun));
+
+	reg_tun->flags = 0;
+

Quoted 2 lines · On Tue, 16 Jan 2007 07:15:17 +0100 [email protected] wrote:

[PATCH 01/06]

Quoted 15 lines

Documentation/auto_tune.txt new file +13 -0

+Any kernel subsystem that has registered a tunable should call
+auto_tune_func() as follows:
+
++-------------------------+--------------------------------------------+
+| Step                    | Routine to call                            |
++-------------------------+--------------------------------------------+
+| Declaration phase       | DEFINE_TUNABLE(name, values...);           |
++-------------------------+--------------------------------------------+
+| Initialization routine  | set_tunable_min_max(name, min, max);       |
+|                         | set_autotuning_routine(name, routine);     |
+|                         | register_tunable(&name);                   |
+| Note: the 1st 2 calls   |                                            |
+|       are optional      |                                            |

Quoted 4 lines

++-------------------------+--------------------------------------------+
+| Alloc | activate_auto_tuning(AKT_UP, &name); |
++-------------------------+--------------------------------------------+
+| Free | activate_auto_tuning(AKT_DOWN, &name); |

So does Free always use AKT_DOWN? why does it matter? Seems unneeded and inconsistent.

How does one activate a tunable for downward adjustment?

Documentation/auto_tune.txt line 318

Quoted 8 lines

Documentation/auto_tune.txt new file +8 -0

+
+2) User part:
+
+As seen above, the only way to activate automatic tuning is from user side:
+- the directory /sys/tunables is created during the init phase.
+- each time a tunable is registered by a kernel subsystem, a directory is
+created for it under /sys/tunables.
+- This directory contains 1 file for each tunable kobject attribute:

Please try to limit text documentation to 80 columns or less.

Quoted 8 lines

Index: linux-2.6.20-rc4/fs/Kconfig
===================================================================

fs/Kconfig +0 -0

@@ -925,6 +925,8 @@ config PROC_KCORE
 	bool "/proc/kcore support" if !ARM
 	depends on PROC_FS && MMU
 

fs/Kconfig config PROC_KCORE · line 928

Quoted 1 line

fs/Kconfig +1 -0

+source "kernel/autotune/Kconfig"

Why is that is the File systems menu? Seems odd to me for it to be there. If it's just because it depends on PROC_FS and SYSFS, then it should just go completely after the File systems menu.

Quoted 6 lines

Index: linux-2.6.20-rc4/include/linux/akt.h
===================================================================

include/linux/akt.h new file +1 -0

@@ -0,0 +1,186 @@
+

include/linux/akt.h line 99

Quoted 1 line

include/linux/akt.h new file +1 -0

+	char flags;	/* Only 2 bits are meaningful: */

Make flags unsigned char so that no sign bit is needed.

include/linux/akt.h line 104

Quoted 5 lines

include/linux/akt.h new file +5 -0

+			/* bit 0: set to 1 if the associated tunable can */
+			/*        be automatically adjusted */
+			/* bits 1: set to 1 if the tunable has been */
+			/*         registered */
+			/* bits 2-7: useless */

unused ??

include/linux/akt.h line 184

Quoted 4 lines

include/linux/akt.h new file +2 -0

+
+extern void fork_late_init(void);

Looks like the wrong header file for that extern.

Randy,

Thanks for reviewing the code!
My comments embedded.
I'll re-send the patches as soon as possible.

Quoted 5 lines · Randy Dunlap

Quoted 2 lines · On Tue, 16 Jan 2007 07:15:17 +0100 [email protected] wrote:

[PATCH 01/06]

<snip>

Quoted 15 lines

Quoted 15 lines

Documentation/auto_tune.txt new file +13 -0

+Any kernel subsystem that has registered a tunable should call
+auto_tune_func() as follows:
+
++-------------------------+--------------------------------------------+
+| Step                    | Routine to call                            |
++-------------------------+--------------------------------------------+
+| Declaration phase       | DEFINE_TUNABLE(name, values...);           |
++-------------------------+--------------------------------------------+
+| Initialization routine  | set_tunable_min_max(name, min, max);       |
+|                         | set_autotuning_routine(name, routine);     |
+|                         | register_tunable(&name);                   |
+| Note: the 1st 2 calls   |                                            |
+|       are optional      |                                            |

Quoted 8 lines

Quoted 4 lines

++-------------------------+--------------------------------------------+
+| Alloc | activate_auto_tuning(AKT_UP, &name); |
++-------------------------+--------------------------------------------+
+| Free | activate_auto_tuning(AKT_DOWN, &name); |

So does Free always use AKT_DOWN? why does it matter? Seems unneeded and inconsistent.

Tuning down is recommended in order to come back to the default tunable value.

I agree with you: today it has quite no effect, except on the tunable value. If we take the ipc's example, grow_ary() just returns if the new tunable value happens to be lower than the previous one.
But we can imagine, in the future, that grow_ary could deallocate the unused memory.
+ in that particular case, lowering the tunable value makes the 1st loop in ipc_addid() shorter.

Quoted 1 line

How does one activate a tunable for downward adjustment?

Actually a tunable is activated to be dynamically adjusted (whatever the direction).
But you are giving me an idea for a future enhancement: we can imagine a tunable that could be allowed to increase only (or decrease only). In that case, we should move the autotune sysfs attribute into an 'up' and a 'down' attribute?

Quoted 6 lines

Quoted 1 line

+extern void fork_late_init(void);

Looks like the wrong header file for that extern.

Actually, I wanted the changes to the existing kernel files to be as small as possible. That's why everything is concentrated, whenever possible, in the added files.

Quoted 22 lines · On Thu, 25 Jan 2007 17:26:31 +0100 Nadia Derbey wrote:

Quoted 21 lines

Quoted 7 lines

Documentation/auto_tune.txt new file +7 -0

+Any kernel subsystem that has registered a tunable should call
+auto_tune_func() as follows:
+
++-------------------------+--------------------------------------------+
+| Step                    | Routine to call                            |
++-------------------------+--------------------------------------------+
+| Declaration phase       | DEFINE_TUNABLE(name, values...);           |

Documentation/auto_tune.txt line 194

Quoted 10 lines

Documentation/auto_tune.txt new file +10 -0

++-------------------------+--------------------------------------------+
+| Initialization routine  | set_tunable_min_max(name, min, max);       |
+|                         | set_autotuning_routine(name, routine);     |
+|                         | register_tunable(&name);                   |
+| Note: the 1st 2 calls   |                                            |
+|       are optional      |                                            |
++-------------------------+--------------------------------------------+
+| Alloc                   | activate_auto_tuning(AKT_UP, &name);       |
++-------------------------+--------------------------------------------+
+| Free                    | activate_auto_tuning(AKT_DOWN, &name);     |

So does Free always use AKT_DOWN? why does it matter? Seems unneeded and inconsistent.

Quoted 1 line

Tuning down is recommended in order to come back to the default tunable value.

Let me try to be clearer. What is Alloc? and why is AKT_UP associated with Alloc and AFK_DOWN associated with Free (whatever that means)?

Quoted 9 lines

I agree with you: today it has quite no effect, except on the tunable value. If we take the ipc's example, grow_ary() just returns if the new tunable value happens to be lower than the previous one. But we can imagine, in the future, that grow_ary could deallocate the unused memory.
+ in that particular case, lowering the tunable value makes the 1st loop
in ipc_addid() shorter.

Quoted 4 lines

Quoted 1 line

How does one activate a tunable for downward adjustment?

Actually a tunable is activated to be dynamically adjusted (whatever the direction).
But you are giving me an idea for a future enhancement: we can imagine a tunable that could be allowed to increase only (or decrease only). In that case, we should move the autotune sysfs attribute into an 'up' and a 'down' attribute?

Couldn't the tunable owner just adjust the min value to a new (larger) min value, e.g.?

Quoted 10 lines

Quoted 9 lines

Quoted 4 lines

+extern void fork_late_init(void);

Looks like the wrong header file for that extern.

Quoted 1 line

Actually, I wanted the changes to the existing kernel files to be as small as possible. That's why everything is concentrated, whenever possible, in the added files.

I suppose that's OK for review, but it shouldn't be merged that way.

---
~Randy

[PATCH 04/06]

Introduces the kobjects associated to each tunable min and max value

Signed-off-by Nadia Derbey <[email protected]>

---
 include/linux/akt.h         |   30 ++++
 include/linux/akt_ops.h     |  311 ++++++++++++++++++++++++++++++++++++++++++++
 kernel/autotune/akt.c       |  120 ++++++++++++++++
 kernel/autotune/akt_sysfs.c |    8 +
 4 files changed, 469 insertions(+)

Index: linux-2.6.20-rc4/include/linux/akt.h
===================================================================

include/linux/akt.h +6 -0

+ * sysfs support (since the min and max can be updated through sysfs).
+ * The abs_value field is used to check that we are not:
+ *   . falling under the very 1st min value when updating the min value
+ *     through sysfs
+ *   . going over the very 1st max value when updating the max value
+ *     through sysfs
  * The type is known when the tunable is defined (see DEFINE_TUNABLE macro).
  */
 struct typed_value {

Index: linux-2.6.20-rc4/kernel/autotune/akt.c
===================================================================

kernel/autotune/akt.c +0 -0

@@ -203,5 +207,121 @@ ssize_t store_tuning_mode(struct auto_tu
 }

kernel/autotune/akt.c +18 -0

+ssize_t show_tunable_min(struct auto_tune *tun_addr, char *buf)
+{
+	ssize_t rc;
+
+	if (tun_addr == NULL) {
+		printk(KERN_ERR
+			" show_tunable_min(): tunable address is invalid\n");
+		return -EINVAL;
+	}
+
+	spin_lock(&tun_addr->tunable_lck);
+
+	rc = tun_addr->min.show(tun_addr, buf);
+
+	spin_unlock(&tun_addr->tunable_lck);
+
+	return rc;
+}

kernel/autotune/akt.c +22 -0

+ */
+ssize_t store_tunable_min(struct auto_tune *tun_addr, const char *buf,
+			size_t count)
+{
+	ssize_t rc;
+
+	if (tun_addr == NULL) {
+		printk(KERN_ERR
+			" store_tunable_min(): tunable address is invalid\n");
+		return -EINVAL;
+	}
+
+	spin_lock(&tun_addr->tunable_lck);
+
+	rc = tun_addr->min.store(tun_addr, buf, count);
+
+	spin_unlock(&tun_addr->tunable_lck);
+
+	return rc;
+}
+
+

kernel/autotune/akt.c +14 -0

+ */
+ssize_t store_tunable_max(struct auto_tune *tun_addr, const char *buf,
+			size_t count)
+{
+	ssize_t rc;
+
+	if (tun_addr == NULL) {
+		printk(KERN_ERR
+			" store_tunable_max(): tunable address is invalid\n");
+		return -EINVAL;
+	}
+
+	spin_lock(&tun_addr->tunable_lck);
+

Quoted 4 lines · On Tue, 16 Jan 2007 07:15:20 +0100 [email protected] wrote:

[PATCH 04/06]

Introduces the kobjects associated to each tunable min and max value

Quoted 8 lines

Index: linux-2.6.20-rc4/kernel/autotune/akt.c
===================================================================

kernel/autotune/akt.c +0 -0

@@ -203,5 +207,121 @@ ssize_t store_tuning_mode(struct auto_tu
 }
 
 

Quoted 6 lines

kernel/autotune/akt.c +6 -0

+
+/*
+ * FUNCTION:    Set operation called by tunable_attr_store (i.e. when a
+ *              string is stored into /sys/tunables/<tunable>/min).
+ *
+ * PARAMETERS:  count: input buffer size (including the '\0')

Quoted 3 lines

+ *
+ * RETURN VALUE: >0: number of characters used from the input buffer
+ * <= 0: failure

I would expect a return value of 0 not to indicate failure; only <0 should do that. So is this a typo or a real case where a return of 0 indicates failure?

Quoted 6 lines

+ */

kernel/autotune/akt.c +3 -0

+ssize_t store_tunable_min(struct auto_tune *tun_addr, const char *buf,
+			size_t count)
+{

Quoted 8 lines

+/*
+ * FUNCTION: Set operation called by tunable_attr_store (i.e. when a
+ * string is stored into /sys/tunables/<tunable>/max).
+ *
+ * PARAMETERS: count: input buffer size (including the '\0')
+ *
+ * RETURN VALUE: >0: number of characters used from the input buffer
+ * <= 0: failure

same question.

[PATCH 05/06]

This patch introduces all that is needed to process per namespace tunables.

---
 include/linux/akt.h   |   12 +++++++
 kernel/autotune/akt.c |   80 ++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 73 insertions(+), 19 deletions(-)

+/*
+ * FUNCTION: This routine gets the actual auto_tune structure for the
+ * tunables that are per namespace (presently only ipc ones).
+ *
+ * RETURN VALUE: pointer to the tunable structure for the current namespace
+ */

kernel/autotune/akt.c +7 -0

+static struct auto_tune *get_ns_tunable(struct auto_tune *p)
+{
+	if (p->flags & TUNABLE_IPC_NS) {
+		char *shift = (char *) p;
+		struct ipc_namespace *ns = current->nsproxy->ipc_ns;
+
+		shift = (shift - (char *) &init_ipc_ns) + (char *) ns;

The following kernel components register a tunable structure and call the auto-tuning routine:
. file system
. shared memory (per namespace)
. semaphore (per namespace)
. message queues (per namespace)

Quoted 7 lines · On Tue, 16 Jan 2007 07:15:22 +0100 [email protected] wrote:

The following kernel components register a tunable structure and call the auto-tuning routine:
. file system
. shared memory (per namespace)
. semaphore (per namespace)
. message queues (per namespace)

This is the part of the patch series which really matters, and I just don't understand it :(

Why do we want to autotune these things? What problem is this patch series solving? Please describe this part of the work much, much more completely, so we can understand the need to add such a large amount of code to the kernel.

It seems strange that the whole feature is Kconfigurable. Please also explain the thinking behind that.

I suspect the patches would be much simpler if you simply required that all these new tunables be of type `long'. About seven eighths of the code would go away. As would most of those eye-popping macros.

2) why autotuning:
There are at least 3 cases where it can be useful
. for workloads that are known to need a big amount of a given resource type (say shared memories), but we don't know what the maximum amount needed will be . to solve the case of multiple applications running on a single system, and that need the same tunable to be adjusted to feet their needs
. to make a system correctly react to eventual peak loads for a given resource usage, i.e. make it tune up *and down* as needed.

In all these cases, the akt framework will enable the kernel to adapt to increasing / decreasing resource consumption:
1) avoid allocating "a priori" a big amount of memory that will be used only in extreme cases. This is the effect of doing an "echo <huge_value>

Quoted 1 line

/proc/sys/kernel/shmmni"

2) the system will come back to the default values as soon as the peak load is over.

Quoted 15 lines · Nadia Derbey

2) why autotuning:
There are at least 3 cases where it can be useful
. for workloads that are known to need a big amount of a given resource type (say shared memories), but we don't know what the maximum amount needed will be . to solve the case of multiple applications running on a single system, and that need the same tunable to be adjusted to feet their needs
. to make a system correctly react to eventual peak loads for a given resource usage, i.e. make it tune up *and down* as needed.

In all these cases, the akt framework will enable the kernel to adapt to increasing / decreasing resource consumption:
1) avoid allocating "a priori" a big amount of memory that will be used only in extreme cases. This is the effect of doing an "echo <huge_value>

Quoted 4 lines

Quoted 1 line

/proc/sys/kernel/shmmni"

2) the system will come back to the default values as soon as the peak load is over.

At least the ipc ones are supposed to be DOS limits not behavior modifiers. I do admit from looking at the code that there are some consequences of increasing things like shmmni. However I think we would be better off with better data structures and implementations that remove these consequences than this autotuning of denial-of-service limits.

I do not fully agree with you:
It is true that some ipc tunables play the role of DoS limits.
But IMHO the *mni ones (semmni, msgmni, shmmni) are used by the ipc subsystem to adapt its data structures sizes to what is being asked for through the tunable value. I think this is how they manage to take into account a new tunable value without a need for rebooting the system: reallocate some more memory on demand.

Now, what the akt framework does, is that it takes advantage of this concept of "on demand memory allocation" to replace a user (or a daemon) that would periodically check its ipcs consumptions and manually adjust the ipcs tunables:
Doing this from the user space would imply a latency that makes it difficult to react fast enough to resources running out.

Now, talking about DoS limits, akt implements them in a sense: each tunable managed by akt has 3 attributes exported to sysfs:
. autotune: enable / disable auto-tuning
. min: min value the tunable can ever reach
. max: max value the tunable can ever reach

Enabling a sysadmin to play with these min and max values makes it possible to refine the dynamic adjustment, and avoid that the tunable reaches really huge values.

Quoted 6 lines · Nadia Derbey

I do not fully agree with you:
It is true that some ipc tunables play the role of DoS limits.
But IMHO the *mni ones (semmni, msgmni, shmmni) are used by the ipc subsystem to adapt its data structures sizes to what is being asked for through the tunable value. I think this is how they manage to take into account a new tunable value without a need for rebooting the system: reallocate some more memory on demand.

Yes, they do. However if you are constantly having to play with shmmni or the others that is the problem and the array should be replaced with a hash table or some form of radix tree, so it changes it's size to fit the need. Once that is done, shmmni does become a simple DOS limit.

So what I'm asking is please fix the problem at the source don't plaster over it.

Quoted 5 lines

Now, what the akt framework does, is that it takes advantage of this concept of "on demand memory allocation" to replace a user (or a daemon) that would periodically check its ipcs consumptions and manually adjust the ipcs tunables:
Doing this from the user space would imply a latency that makes it difficult to react fast enough to resources running out.

There may be some sense in this but you haven't found something that inherently needs tuning. You have found something that has a poor data structure, and can more easily be fixed by simply fixing the data structure.

So, should I understand from this that automatic tuning and the AKT framework itself would make sense, given that I find the rigth tunables it should be applied to?

Actually, dont' know if you had the opportunity to read all the patches, but there are 2 other tunables AKT is proposed to be applied to:
. max_threads, the tunable limit on nr_threads
. max_files, the tunable limit on nr_files

Quoted 3 lines · Nadia Derbey

So, should I understand from this that automatic tuning and the AKT framework itself would make sense, given that I find the rigth tunables it should be applied to?

Sort of. The concept of things tuning themselves automatically makes a lot of sense.

I'm not at all certain about tunables being exported just to be hidden again. Ideally you don't even want the fact that these things are varying visible to the user.

So I think that if you can find a good example that cannot be solved better another way, you can build a case for your framework. Currently I am doubt you can find such a case.

Quoted 4 lines

Actually, dont' know if you had the opportunity to read all the patches, but there are 2 other tunables AKT is proposed to be applied to:
. max_threads, the tunable limit on nr_threads
. max_files, the tunable limit on nr_files

At a quick glance max_threads and max_files appear even more to be DOS limits and not tunables and even less applicable to needing any tuning at all. My gut feel is at worst these values may need a little better boot time defaults but otherwise they the should be good.

But, what do you do with Oracle that's asking maxfiles to be set to 0x10000, while the default value might be enough for a system that's not running Oracle. I'm afraid that giving boot time values to the max_* tunables we will loose all the benefits from /proc (or /sys): it is impossible to anticipate what an OS will be used for. So allowing such things to be changed without having to reboot the machine is in my mind quite a powerful feature we should keep taking adavntage of.

Quoted 7 lines · Nadia Derbey

But, what do you do with Oracle that's asking maxfiles to be set to 0x10000, while the default value might be enough for a system that's not running Oracle. I'm afraid that giving boot time values to the max_* tunables we will loose all the benefits from /proc (or /sys): it is impossible to anticipate what an OS will be used for. So allowing such things to be changed without having to reboot the machine is in my mind quite a powerful feature we should keep taking adavntage of.

I'm not saying remove user spaces' ability to set the denial-of-service limits. I'm saying if they need to be frequently changed we need to update the default so they are higher by default.

There really is no cost in moving those values up and down it is just an arbitrary integer used in comparisons. But if we can make a good guess that still catches runaway programs before they kill the machine but also allows more programs to work out of the box we are in better shape.