<div dir="ltr"><font face="monospace, monospace">Hi Jeff,</font><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">(Disclaimer, switched to gmail, responding via gmail web interface, hopefully this formats well.</font></div><div class="gmail_extra"><font face="monospace, monospace"><br></font><div class="gmail_quote"><font face="monospace, monospace">On Mon, Jul 6, 2015 at 8:34 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="monospace, monospace">> And in the past, if not now, are contributing factors to small file<br>
> performance issues.<br>
<br>
I'm not quite seeing the connection here. Which macros are you<br>
thinking of, and how does the fact that they're macros instead of<br>
functions make them bad for small-file performance? AFAIK the<br>
problem with some of the macros in storage/posix is the redundant<br>
xattr calls etc. that some of them make. Is the idea here that<br>
with inline code (not inline functions) each instance could be<br>
more closely tuned to a particular need and avoid the redundant<br>
calls?<br></font></blockquote><div><br></div><div><font face="monospace, monospace">From my past analysis of a small file workload strace, <a href="https://gist.github.com/portante/5029518">https://gist.github.com/portante/5029518</a>, I saw that the macros hid gratuitous behaviors. It seems that we need to be careful that macros are used knowing what they are doing. Digging through the strace (annotated from code that I am sure has since changed) it was quite amazing to see what happens for one operation.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">-peter </font></div></div><br></div></div>