lkml.org 
[lkml]   [2004]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] deinline large functions in sock.h
Date
> > Inline staistics for this file:
> >
> > Size Uses Wasted Name and definition
> > ===== ==== ====== ================================================
> > 381 21 7220 sock_queue_rcv_skb include/net/sock.h
>
> yup, this looks long.
>
> > 101 18 1377 sock_orphan include/net/sock.h
>
> only used in close, release path

Okay, so is it pro- or contra- argument for inlining?

> > 90 18 1190 sk_del_node_init include/net/sock.h
> > 150 8 910 sk_dst_reset include/net/sock.h
> > 44 31 720 skb_set_owner_w include/net/sock.h
> > 53 18 561 sk_add_node include/net/sock.h
>
> in main path, and should be small for most cases
>
> > 61 10 369 sock_recv_timestamp include/net/sock.h
>
> probably critical path, be careful.

I did not touch it, it's 60 bytes (less than 90).

> > 55 10 315 sock_i_ino include/net/sock.h
> > 55 9 280 sock_i_uid include/net/sock.h
> > 97 4 231 sk_filter include/net/sock.h
> > 236 2 216 sk_dst_check include/net/sock.h
>
> only used by udp and decnet, probably not a big win.

Again, I didnt understand here what do you mean:
"ok to deinline" or "keep inlined" ?

> > 194 2 174 sock_queue_err_skb include/net/sock.h
> > 103 3 166 sock_graft include/net/sock.h
> > 66 3 92 sk_dst_get include/net/sock.h
> > 63 3 86 __sk_dst_reset include/net/sock.h
> > 45 4 75 __sk_dst_check include/net/sock.h
> > 63 2 43 __sk_dst_set include/net/sock.h
> > 46 2 26 sk_filter_release include/net/sock.h
> > 46 2 26 sk_add_bind_node include/net/sock.h
> > 46 2 26 __sk_add_node include/net/sock.h
> >
> > Included are two patches. They deinline functions which are larger
> > than ~90 bytes.
> >
> > Why two patches? I realize that since inlining/deinlining of
> > a function can happen multiple times as kernel evolves,
> > it can be very inconvenient to move function definition
> > from .h to .c file and back.
> >
> > First patch simply does such a move.
> >
> > Second does not. Instead it adds _inlined suffix to
> > the functions and a controlling #define. If it is #defined to 1,
> > function will be inlined. Otherwise not.
> > At the first glance it looks, well, ugly as hell:
>
> It still look ugly, just make up your mind. and do it or not!

I thought about functions becoming larger/smaller
when somebody modifies logic of relevant network subsystem.
One-liners may turn into ten-liners, and vice versa.

> > Ugliness can be reduced somewhat with macros.
>
> No macro's generally increase ugliness sorry.

I don't push it. Just wanted to know what others think.
--
vda

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

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.036 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site