Messages in this thread | | | Date | Mon, 31 Mar 1997 09:43:28 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: 2.1 kernel bloat revisited |
| |
From: Eric.Schenk@dna.lth.se Date: Sat, 29 Mar 1997 18:25:25 +0100
>Symbol Old size New size Delta Change >SHATransform 00006796 00000364 -6432 -94.6439 >[ A good guy :) ]
Actually, a bad guy, in another sense. This is one of the most expensive routines to execute on the critical path for accepting a TCP connection. (It gets called to generate secure sequence numbers). If you shrink it down, you double the execution time. David and I have been talking about what to do with this one, probably we'll make it a compile time option to choose between "small and slow" and "big and fast".
What percentage of the time spent in a TCP open is due to SHATransform? And are there boxes which are doing enough TCP opens that this is cuasing a measurable difference?
There are some hand coded SHA implementations in assembly that I haven't really bothered with because SHATransform isn't part of the critical path for /dev/random. But if this is really a concern, there are SHA implementations which are smaller and faster than the current "big and fast" version which is written in C.
- Ted
| |