[tor-bugs] #9682 [Tor]: Better work queue implementation for cpuworkers
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Nov 26 20:41:53 UTC 2013
#9682: Better work queue implementation for cpuworkers
-----------------------------+---------------------------------------------
Reporter: nickm | Owner:
Type: enhancement | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version:
Resolution: | Keywords: tor-relay performance cpuworker
Actual Points: | Parent ID:
Points: |
-----------------------------+---------------------------------------------
Comment (by dgoulet):
In terms of locking and synchronization, this looks good to me! I just
have some basic questions.
* In workerthread_t data structure, I don't see any use of is_running or
is_shut_down other then setting them to one. I guess you are plaining
ahead or leftovers?
* I'm wondering if "waiting" (in workerthread_t) is really useful.
tor_cond_signal_one() will simply do nothing if no thread is waiting. I
guess one can argue that with the if(waiting) you can avoid a libc call
but not sure if it is a gain in performance.
Just a suggestion. In terms of benchmark, one thing that can be very
helpful for that is user space tracing. Basically, you add "Trace Event"
to the code base which can record a payload of your choice and provide
very very accurate timings along with possible extra informations (perf
counters, tid, ...) when it's triggered. It gather a trace that can be
analyzed later on or live, and with LTTng for instance, it's not going
through the kernel at each event unlike Dtrace or Systemtap thus it's high
performance and low intrusiveness.
I'll be happy to cook a branch with that support and you can see if it's
useful to you or not. The tools are packaged in Debian/Ubuntu/Arch.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9682#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list