Re: [PATCH 00/69] faster tree-based sysctl implementation

[Lucian Adrian Grijincu]

On Mon, May 2, 2011 at 12:49 AM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
>>> Since we are touching most if not all of the sysctl registrations this
>>> would also be a good time to pass a path string instead of the weird
>>> ctl_path data structure. ÂWe needed ctl_path when we had both binary
>>> and proc paths to worry about but we no longer have that concern.
>>
>>
>> I still find good use for it in the next patches (some optimisations).
>> Getting rid of it makes some things more difficult:
>> - I wouldn't like to parse strings into path components at registeration
>
> I don't expect '/' being more difficult to deal with than an array. ÂIn
> general I expect a single string to be more space efficient and easier
> for human comprehension.


We also use the string from ctl_path as a name for the sysctl
directory. We would need to either:
* strdup part of the string for each directory, remember to kfree
* replace '/' with '\0' in the given string (meaning it can't be put
in a read-only zone)

Also I make use of the ctl_path to add some optimisations that deal
with the case when there are very many known-to-be-uniquely-named
sub-directories like for /proc/sys/net/ipv4/conf/DEVICE. IXIACOM which
sponsored this work has usecases where they need to create 10^3..10^5
virtual network devices and these optimisations really add up for that
many interfaces.

For details about the optimisation see patches:
 61/69 http://thread.gmane.org/gmane.linux.kernel/1133667/focus=1133694 and
 62/69 http://thread.gmane.org/gmane.linux.kernel/1133667/focus=1133711


I will make another function that would take a string, parse it up,
create a ctl_path array and register it, but I'd really like to keep
ctl_path both in the implementation and as a means to register a
table.

>> - users of the register_sysctl_paths would need to create strings with
>> dynamic components (for example "net/conf/%s/" - where %s is a
>> netdevice-name or "kernel/sched_domain/%s/%s" with cpu-name and
>> domain-name).
>
> This is a good point.
>
> In the normal proc implementation this is solved by being able to
> pass the equivalent of a ctl_table_header into the registration
> function, which allows the use of relative paths in the registration
> function.
>
> In the examples you have given relative paths should also work for
> sysctl.


Hmm, I don't think we're on the same channel here. I don't understand
what you're trying to say
- normal proc implementation?
- the equivalent of a ctl_table_header?
- relative paths?

I was saying that if we are to *replace* the ctl_path based mechanism
with a string denoting the path, then some other registrants will need
to allocate memory for those strings because the paths they register
are computed at runtime. Then I gave two distinct examples where this
is done. In both of those cases, ctl_path saves us from allocating a
string before allocation, only to chop it then back to pieces in the
__register function.



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