All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] iomap: Remove indirect function call
Date: Tue, 31 Mar 2020 06:02:52 -0700	[thread overview]
Message-ID: <20200331130252.GA21484@bombadil.infradead.org> (raw)
In-Reply-To: <20200331074628.GA9872@infradead.org>

On Tue, Mar 31, 2020 at 12:46:28AM -0700, Christoph Hellwig wrote:
> On Sat, Mar 28, 2020 at 08:51:56AM -0700, Matthew Wilcox wrote:
> > By splitting iomap_apply into __iomap_apply and an inline iomap_apply,
> > we convert the call to 'actor' into a direct function call.  I haven't
> > done any performance measurements, but given the current costs of indirect
> > function calls, this would seem worthwhile to me?
> 
> Hmm.  Given that emount of compiler stupidity we are dealing with did
> you at least look at the assembly output to see if this actually removes
> the indirect call?  I wouldn't be quite sure.

If it does get inlined, then the compiler does it:

     b9d:       e8 ae fe ff ff          callq  a50 <iomap_page_mkwrite_actor>

If not, then the compiler emits a function in each file called iomap_apply
which makes an indirect call.  So s/inline/__always_inline/ in the original
patch.

before:
   text	   data	    bss	    dec	    hex	filename
   5314	   4648	      0	   9962	   26ea	fs/iomap/trace.o
   1050	     72	      0	   1122	    462	fs/iomap/apply.o
  17316	    636	    224	  18176	   4700	fs/iomap/buffered-io.o
   4773	     76	      0	   4849	   12f1	fs/iomap/direct-io.o
   1335	     28	      0	   1363	    553	fs/iomap/fiemap.o
   1928	     28	      0	   1956	    7a4	fs/iomap/seek.o
   1394	      8	      0	   1402	    57a	fs/iomap/swapfile.o

after:
   text	   data	    bss	    dec	    hex	filename
   5314	   4648	      0	   9962	   26ea	fs/iomap/trace.o
    722	     72	      0	    794	    31a	fs/iomap/apply.o
  18784	    636	    224	  19644	   4cbc	fs/iomap/buffered-io.o
   5169	     76	      0	   5245	   147d	fs/iomap/direct-io.o
   2093	     28	      0	   2121	    849	fs/iomap/fiemap.o
   2467	     28	      0	   2495	    9bf	fs/iomap/seek.o
   1664	      8	      0	   1672	    688	fs/iomap/swapfile.o

33110 to 36213 bytes of text.  So not free.  Worthwhile?

      reply	other threads:[~2020-03-31 15:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-28 15:51 [RFC] iomap: Remove indirect function call Matthew Wilcox
2020-03-31  7:46 ` Christoph Hellwig
2020-03-31 13:02   ` Matthew Wilcox [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200331130252.GA21484@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.