On Thu, 25 Jan 2007 17:26:31 +0100 Nadia Derbey wrote:+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 | |
++-------------------------+--------------------------------------------+
+| 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.
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)?
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.
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.?
+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.
I suppose that's OK for review, but it shouldn't be merged that way.
---
~Randy