On Fri, 7 Dec 2007, David Miller wrote:
quoted text
> 
> Also I could end up being performance limited by SHA, it's not very
> well tuned on Sparc.  It's been on my TODO list to code up the crypto
> unit support for Niagara-2 in the kernel, then work with Herbert Xu on
> the userland interfaces to take advantage of that in things like
> libssl.  Even a better C/asm version would probably improve GIT
> performance a bit.

I doubt yu can use the hardware support. Kernel-only hw support is 
inherently broken for any sane user-space usage, the setup costs are just 
way way too high. To be useful, crypto engines need to support direct user 
space access (ie a regular instruction, with all state being held in 
normal registers that get saved/restored by the kernel).

quoted text
> Is SHA a significant portion of the compute during these repacks?
> I should run oprofile...

SHA1 is almost totally insignificant on x86. It hardly shows up. But we 
have a good optimized version there.

zlib tends to be a lot more noticeable (especially the uncompression: it 
may be faster than compression, but it's done _so_ much more that it 
totally dominates).

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html