lkml.org 
[lkml]   [2007]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 1/6] Tunable structure and registration routines
Randy Dunlap wrote:
> 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)?

Alloc stands for resource allocation: in a subsystem where resource
allocation depends on a tunable value, we should tune up that value
prior to the alllocation itself. Let's come back to the ipc subsystem
example: ipc_addid() is the routine that adds an entry to an ipc array.
The 1st thing it does (via grow_ary()) is to allocate some more space
for the ipc array if needed, i.e. if the ipc tunable value has
increased. That's why the tunable should be tuned up before calling
ipc_addid().

AKT_DOWN is the reverse operation: we are freeing resources, so the
tunble has no reason to remain with a big 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.
>>
>>
>>>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.?

You're completely right: setting the min value to the default one should
be enough!

>
>
>
>>>>+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
>


Regards,
Nadia

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-01-25 18:01    [W:0.051 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site