Re: [PATCH net-next-2.6] filter: optimize sk_run_filter

[Eric Dumazet <eric.dumazet@gmail.com>]

Le vendredi 19 novembre 2010 à 08:21 -0800, David Miller a écrit :

> -EFIX_THE_DAMN_COMPILER
> 
> We never make calls out of this function or touch volatile memory or
> create a full memory barrier between the assignment of f_k and it's
> uses.
> 
> Therefore if common sub-expression elimination is working the compiler
> will be able to decide properly whether to access things via memory or
> use a register for the value.
> 
> Remember this is why we have that ACCESS_ONCE() thing.
> 
> We can't have it both ways, either ACCESS_ONCE() should be removed or
> we should never make changes like your's and instead should submit
> compiler bug reports :-)

Compiler is OK IMHO in this case. It does exactly what is required.

Compiler cannot load fentry->k before the switch() if some expression
dont use it, as it could trigger a fault.

After the "f_k = fentry->k;" commit, it was requested to do so.

Unfortunatly on x86_32 it also chose that f_k was more valuable in a cpu
register and accumulator A lost its register to get a stack slot
instead.

Not many BPF instructions use K, and if used, its used _once_ per BPF
instruction. There is no real gain to put it on a register, but code
size if (and only if) it is held in a cpu register, because each
assembler instruction using a register instead of stack is a bit
shorter.

In the end, I believe the "f_k = fentry->k;" was a good looking idea,
and good for some arches, but we forgot x86_32 (and probably some others)
have few available registers to play with.

Have a good week end !