On Sun, Apr 2, 2017 at 6:18 PM, Alexey Dobriyan <adobri...@gmail.com> wrote:
> Number of sockets is limited by 16-bit, so 64-bit allocation will never
> happen.
>
> 16-bit ops are the worst code density-wise on x86_64 because of
> additional prefix (66).
So this boils down to a compiled code density vs a
readability/maintainability argument? I'm not familiar with the 16
bit problem you're referring to, but I'd argue that using the
self-documenting u16 as an input parameter to define the range
expectations is more useful that the micro optimization that this
change may buy you in the assembly of one platform. Especially given
that this is a rare-use function.
>
> Space savings:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3 (-3)
> function old new delta
> reuseport_add_sock 539 536 -3
>
> Signed-off-by: Alexey Dobriyan <adobri...@gmail.com>
> ---
>
> net/core/sock_reuseport.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/net/core/sock_reuseport.c
> +++ b/net/core/sock_reuseport.c
> @@ -13,9 +13,9 @@
>
> static DEFINE_SPINLOCK(reuseport_lock);
>
> -static struct sock_reuseport *__reuseport_alloc(u16 max_socks)
> +static struct sock_reuseport *__reuseport_alloc(unsigned int max_socks)
> {
> - size_t size = sizeof(struct sock_reuseport) +
> + unsigned int size = sizeof(struct sock_reuseport) +
> sizeof(struct sock *) * max_socks;
> struct sock_reuseport *reuse = kzalloc(size, GFP_ATOMIC);
>
