On Fri, Dec 8, 2017 at 9:24 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Fri, 2017-12-08 at 19:29 +0800, Tonghao Zhang wrote:
>> hi all. we can add synchronize_rcu and rcu_barrier in
>> sock_inuse_exit_net to
>> ensure there are no outstanding rcu callbacks using this network
>> namespace.
>> we will not have to test if net->core.sock_inuse is NULL or not from
>> sock_inuse_add(). :)
>>
>> static void __net_exit sock_inuse_exit_net(struct net *net)
>> {
>> free_percpu(net->core.prot_inuse);
>> +
>> + synchronize_rcu();
>> + rcu_barrier();
>> +
>> + free_percpu(net->core.sock_inuse);
>> }
>
>
> Oh well. Do you have any idea of the major problem this would add ?
>
> Try the following, before and after your patches :
>
> for i in `seq 1 40`
> do
> (for j in `seq 1 100` ; do unshare -n /bin/true >/dev/null ; done) &
> done
> wait
>
> ( Check commit 8ca712c373a462cfa1b62272870b6c2c74aa83f9 )
>
Yes, I did the test. The patches drop the performance.
Before patch:
# time ./add_del_unshare.sh
net_namespace 97 125 6016 5 8 : tunables 0 0
0 : slabdata 25 25 0
real 8m19.665s
user 0m4.268s
sys 0m6.477s
After :
# time ./add_del_unshare.sh
net_namespace 102 130 6016 5 8 : tunables 0 0
0 : slabdata 26 26 0
real 8m52.563s
user 0m4.040s
sys 0m7.558s
>
> This is a complex problem, we wont accept patches that kill network
> namespaces dismantling performance by adding brute force
> synchronize_rcu() or rcu_barrier() calls.
>
> Why not freeing net->core.sock_inuse right before feeing net itself in
> net_free() ?
I try this way, alloc core.sock_inuse in net_alloc(), free it in net_free ().
It does not drop performance, and we will not always to check the
core.sock_inuse
in sock_inuse_add().
After :
# time ./add_del_unshare.sh
net_namespace 109 135 6016 5 8 : tunables 0 0
0 : slabdata 27 27 0
real 8m19.265s
user 0m4.090s
sys 0m8.185s
> You do not have to hijack sock_inuse_exit_net() just because it has a
> misleading name.
>
>
