Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751835AbdFUTpI (ORCPT ); Wed, 21 Jun 2017 15:45:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39234 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038AbdFUTpH (ORCPT ); Wed, 21 Jun 2017 15:45:07 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A76B4B9AA4 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dvlasenk@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A76B4B9AA4 Subject: Re: [PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes To: Marcelo Ricardo Leitner References: <20170621170327.4873-1-dvlasenk@redhat.com> <20170621192442.GH18138@localhost.localdomain> Cc: linux-kernel@vger.kernel.org, Vlad Yasevich , Neil Horman , David Miller , linux-sctp@vger.kernel.org, netdev@vger.kernel.org From: Denys Vlasenko Message-ID: <8d25a6ac-8733-8ab6-7edf-601d45402d53@redhat.com> Date: Wed, 21 Jun 2017 21:45:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170621192442.GH18138@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 21 Jun 2017 19:45:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2360 Lines: 53 On 06/21/2017 09:24 PM, Marcelo Ricardo Leitner wrote: > On Wed, Jun 21, 2017 at 07:03:27PM +0200, Denys Vlasenko wrote: >> This function compiles to 147 bytes of machine code. 13 callsites. >> >> I'm no expert on SCTP events, but quick reading of SCTP docs tells me that >> SCTP events are not happening on every packet. >> They are ASSOC_CHANGE, PEER_ADDR_CHANGE, REMOTE_ERROR and such. >> Does not look performance critical. >> >> Signed-off-by: Denys Vlasenko >> CC: Vlad Yasevich >> CC: Neil Horman >> CC: David Miller >> CC: linux-sctp@vger.kernel.org >> CC: netdev@vger.kernel.org >> CC: linux-kernel@vger.kernel.org > > Acked-by: Marcelo Ricardo Leitner > > Just wondering, are you conducting further research on this topic? > Because we probably could use such review on SCTP stack. Here is the list of sctp inlines which has any (however small) benefit when deinlined. filename:lineno:inline_name:lines_of_source_code:saved_bytes_by_deinlining:size_of_code_of_deinlined_function include/net/sctp/command.h:228:sctp_add_cmd_sf:7:8306:38 net/sctp/ulpevent.c:91:sctp_ulpevent_set_owner:13:1616:147 include/net/sctp/sctp.h:414:sctp_skb_set_owner_r:10:934:75 net/sctp/input.c:840:sctp_hash_key:13:896:359 net/sctp/input.c:823:sctp_hash_obj:13:704:409 include/net/sctp/checksum.h:60:sctp_compute_cksum:13:595:85 net/sctp/input.c:800:sctp_hash_cmp:18:320:124 net/sctp/socket.c:117:sctp_wspace:19:256:76 include/net/sctp/sctp.h:272:sctp_max_rto:7:204:68 net/sctp/socket.c:173:sctp_verify_addr:15:192:72 include/net/sctp/checksum.h:46:sctp_csum_update:4:147:21 include/net/sctp/sctp.h:519:param_type2af:8:134:35 include/net/sctp/sctp.h:399:sctp_list_dequeue:7:123:59 include/net/sctp/sctp.h:596:sctp_transport_dst_check:4:120:60 include/net/sctp/sctp.h:435:sctp_frag_point:12:65:65 net/sctp/outqueue.c:82:sctp_outq_dequeue_data:10:64:87 include/net/sctp/command.h:243:sctp_next_cmd:4:64:37 include/net/sctp/sm.h:347:sctp_data_size:6:19:19 For .c files, the patches are trivial and I have them auto-generated, I'll send them to you privately to save you the mechanical work. Unfortunately, for inlines in .h files this does not work (a human is needed to decide where to more the function). Of course, not every deinlining makes sense.