Messages in this thread | | | Date | Thu, 25 Jan 2007 18:01:34 +0100 | From | Nadia Derbey <> | Subject | Re: [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/
| |