On 2013-11-10 08:09, Bastian Bittorf wrote:
> * Felix Fietkau <[email protected]> [10.11.2013 08:00]:
>> > hotplug-call: script: /etc/hotplug.d/iface/00-netstate READY: 1194
>> > hotplug-call: script: /etc/hotplug.d/iface/15-teql START: 1194
>> > hotplug-call: script: /etc/hotplug.d/iface/15-teql READY: 1194
>> > hotplug-call: script: /etc/hotplug.d/iface/30-6relay START: 1194
>> > hotplug-call: script: /etc/hotplug.d/iface/30-6relay READY: 1194
>> > hotplug-call: script: /etc/hotplug.d/iface/50-olsrd START: 1194
>> > hotplug-call: script: /etc/hotplug.d/iface/50-olsrd READY: 1194
>> > hotplug-call: $1 = 'iface' READY: 1194
>> What do these numbers mean?
>
> the process-id, so we can see/count forks.
It probably isn't showing the subshell pid initiated by ().
>> > is it really needed to run in parallel? maybe it can be made configurable
>> > to run one after another?
>> They are called from different processes, so they cannot easily be
>> serialized. net is called by hotplug2 (on AA) / procd (on BB). iface is
>> called by netifd.
>
> maybe all goes into a queue which procd runs?
I'd like to keep it in netifd, because I want to avoid adding special
cases for things like suppressing redundant events for a single interface.
>> > are the 'micro-optimizations' and nobody cares or is this ok?
>> I'd like to avoid such micro-optimization churn unless you can prove
>> that it actually matters.
>
> this is easy:
> for I in $(seq 0 10000); do UP="$( sed -ne 's![^0-9].*$!!p' /proc/uptime )";
> done
> for I in $(seq 0 10000); do read UP REST </proc/uptime; UP=${UP%.*}; done
>
> sed-variant:
> real 1m 10.10s
> user 0m 18.52s
> sys 0m 48.83s
>
> internal calls:
> real 0m 3.25s
> user 0m 1.82s
> sys 0m 1.42s
>
> 3 sec vs. 70 sec...
> this was done on a strong board, on a weak board the difference is much
> bigger.
> This is only _one_ little optimization, and there are a lot of...
For it to matter, I'm more interested in the absolute time saved than
relative differences on a completely unrealistic number of iterations.
In the case you're describing, it's still only saving about 7 ms per
interface-up event, that's not a lot.
By the way, I found an even faster way to deal with that particular
call: https://dev.openwrt.org/changeset/38704 :)
- Felix
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
