Mike Perry wrote:

Thus spake swsnyder at snydernet.net (swsnyder at snydernet.net):

...

FYI, this is a profile of my Tor v0.2.2.30-rc relay, taken in a 10-minute sampling:

CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % linenr info symbol name 3126 29.7290 cast-586.s:9 CAST_encrypt

Can you attach gdb to your relay and set a breakpoint for CAST_encrypt? We have no idea why this function should be called at all (unless it is for something like reading keyfiles off disk?) let alone dominate your profile output.

I didn't break on CAST_encrypt() either in a running process or in tor started from a gdb command line. Either way, I could set a breakpoint on the symbol but never actually got there.

I think the symbols were screwed-up from building Tor with GCC's Profile Guided Optimization. When I built the same code without PGO I get this from another 10-minute run:

CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % linenr info symbol name 2386 58.6241 x86-mont.s:8 bn_mul_mont 262 6.4373 aes-586.s:269 _sse_AES_encrypt_compact 207 5.0860 sha1-586.s:8 sha1_block_data_order 199 4.8894 aes-586.s:424 _x86_AES_encrypt 189 4.6437 aes-586.s:1610 _x86_AES_decrypt 55 1.3514 aes.c:329 aes_crypt_inplace 48 1.1794 di_ops.c:97 tor_memeq

Breakpoints *do* hit on bn_mul_mont(). I assume the reduced number of samples is a result of only having half as many active connection as the prior profiling run.

Thanks for the reply.