From: Herbert Xu Subject: Re: sha-512... Date: Wed, 15 Feb 2012 16:16:08 +1100 Message-ID: <20120215051608.GA9126@gondor.apana.org.au> References: <20120214.225833.303014660389989764.davem@davemloft.net> <20120215040128.GA8738@gondor.apana.org.au> <20120215.001113.86424501006520715.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-crypto@vger.kernel.org, Linus Torvalds , Alexey Dobriyan To: David Miller Return-path: Received: from helcar.apana.org.au ([209.40.204.226]:49043 "EHLO fornost.hengli.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751530Ab2BOFQM (ORCPT ); Wed, 15 Feb 2012 00:16:12 -0500 Content-Disposition: inline In-Reply-To: <20120215.001113.86424501006520715.davem@davemloft.net> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Wed, Feb 15, 2012 at 12:11:13AM -0500, David Miller wrote: > > > On Tue, Feb 14, 2012 at 10:58:33PM -0500, David Miller wrote: > >> > >> FYI, I just started seeing this on sparc32 after all those > >> sha512 "optimizations": > >> > >> crypto/sha512_generic.c: In function 'sha512_transform': > >> crypto/sha512_generic.c:135:1: warning: the frame size of 1136 bytes is larger than 1024 bytes [-Wframe-larger-than=] > > > > Is that with the latest patch applied? > > > > crypto: sha512 - Avoid stack bloat on i386 > > > > If so then this is not good. > > Yes. And, of course, with that commit reverted it's even worse. > Reverting it makes the stack frame twice as large. > > > What was the original stack usage, i.e., if you revert to the > > original percpu code? > > If I revert: > > commit 3a92d687c8015860a19213e3c102cad6b722f83c > commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd > commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 > commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d > > the stackframe goes down to 888 bytes. > > More detailed, the progression is: > > master 1136 > revert 3a92d687c8015860a19213e3c102cad6b722f83c 2408 > revert 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd 2408 > revert 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 1520 > revert 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d 888 OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of that is expected since we moved W onto the stack. I guess we could go back to the percpu solution, what do you think? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt