[Top] [All Lists]

Re: [PATCH 1/2] Make stuff static

To: chatz@xxxxxxxxxxxxxxxxx
Subject: Re: [PATCH 1/2] Make stuff static
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 22 Nov 2006 10:13:15 -0600
Cc: David Chinner <dgc@xxxxxxx>, Russell Cattelan <cattelan@xxxxxxxxxxx>, Tim Shimmin <tes@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4563D7DD.1060907@melbourne.sgi.com>
References: <45338DDE.8020903@sandeen.net> <4533FAEA.2080500@sandeen.net> <20061016232250.GM11034@melbourne.sgi.com> <1161042943.5723.117.camel@xenon.msp.redhat.com> <20061017005038.GN11034@melbourne.sgi.com> <AED98B89E193744D39BAC541@pmmelb207.melbourne.sgi.com> <20061017215706.GI8394166@melbourne.sgi.com> <1161125131.5723.158.camel@xenon.msp.redhat.com> <20061122004216.GT11034@melbourne.sgi.com> <1164157783.19915.46.camel@xenon.msp.redhat.com> <20061122042445.GR37654165@melbourne.sgi.com> <4563D7DD.1060907@melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20061025)
David Chatterton wrote:

David Chinner wrote:

Just reducing xfs_bmapi by 118 bytes makes this worthwhile doesn't it?

Out of interest, what estimated improvement does this have on one of Jesper's

Should we be concerned that there are now more functions with 100 or more bytes?

I don't think we need to worry about that, it is probably in the noise.

There will almost certainly be fallout from this change w.r.t. 4k stacks. It should probably at least be tested on 4k stacks over a fairly complex volume setup to see.

Also with respect to stack usage, is there extra stack space used, in addition to the explicit %esp adjustments, to set up each function call?

IOW is the total more than the sum of the parts? :)

I'm glad to hear that there's no apparent performance penalty....


<Prev in Thread] Current Thread [Next in Thread>