thread_ptrace: use unbuffered IO by default#1290
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #1290 +/- ##
==========================================
- Coverage 55.67% 55.65% -0.02%
==========================================
Files 141 141
Lines 20616 20619 +3
Branches 5067 5068 +1
==========================================
- Hits 11478 11476 -2
- Misses 6017 6020 +3
- Partials 3121 3123 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
src/main/host/thread_ptrace.c
Outdated
| "otherwise result in excessive detaching and reattaching", | ||
| NULL) | ||
|
|
||
| static bool _useBufferedIo = false; |
There was a problem hiding this comment.
Steve just renamed a bunch of these _useXXX switch variables, so maybe we should follow his pattern?
Although I think he was just aiming to make it so that the default for all of the options is false. Anyway, I guess _enableBufferedIo would be more consistent with his change?
There was a problem hiding this comment.
Good point; done
There was a problem hiding this comment.
We decided to remove the --disable and --enable prefixes from options, so this PR isn't needed anymore.
I guess I should still use the --enable prefix here, and they'll all be changed in another PR?
There was a problem hiding this comment.
I closed that PR since I thought we wanted to not use the --enable or --disable prefixes anymore.
|
For posterity: I ran a Tor 5% net with memory manager disabled using Jim’s byte queue commit aed8b71. It looks like unbuffered IO indeed is the winner. |
Buffering only helps when doing small sequential accesses. For syscalls that do large accesses (read, write), buffering just adds an extra copy.
Smaller accesses are generally small structs; not many handlers access more than one, and even then it only helps if they happen to be sequential in memory.