-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Too many calls to futex #127
Comments
I introduced pthreads just to be sure:
The futex here is the pthread_join. |
I have a minimal reproducer in a branch https://github.com/toffaletti/swift-nio/blob/wtfutex/Sources/WTFutex/main.swift |
Got it:
internal enum EventFd {
public static let EFD_CLOEXEC = CNIOLinux.EFD_CLOEXEC <-- Every |
@jckarter @gparker42 Anything to be done about this? SwiftNIO is using |
Optimization seems to eliminate all futex calls in the reduced repro, but I still see a lot of futex calls in
|
Looks like
The rest seem to be in SwiftNIO from the lock protecting
|
This is definitely worth diving into to see if we can elide the calls to I'm going to reach out to some folks on the Swift team and see if they have any particular thoughts on whether we can avoid this, but I suspect it's basically unavoidable for generic classes like |
(Naturally it goes without saying that the |
Does the futex happen on every access, or only the first? We could consider using |
Yes, it would help if you could distinguish between futex accesses during launch time or at first use, versus futex accesses during steady-state operation. Both are worth investigating to improve performance, but the latter would be a more significant problem. |
Thanks, I will work on teasing those apart. The issue I'm running into now is that I have to use an optimized build which makes debugging a bit more difficult and I haven't figured out a way to make gdb only pause execution on the futex calls in the thread I care about and pausing on all threads calls to futex seems to introduce different behavior because of timeouts and various timing issues. I might need to resort to a different tool. |
We should look into this |
I think this is the over side of this issue: |
Motivation: Warnings are bad, let's make them errors. Modifications: enable `-warnings-as-errors` Result: Fewer warnings.
@Lukasa et al: I think we can close this issue. I recently made some perf analysis at work and I counted every single syscall in a program that doesn't use Program let group = MultiThreadedEventLoopGroup(numberOfThreads: Int(CommandLine.arguments.dropFirst().first!)!)
defer {
try! group.syncShutdownGracefully()
}
let allDone = group.next().makePromise(of: Int.self)
func doIt(allDone: EventLoopPromise<Int>, n: Int, accumulator: Int) {
guard n > 0 else {
allDone.succeed(accumulator)
return
}
group.next().makeSucceededFuture(1).flatMap { one in
group.next().makeSucceededFuture(one + 1)
}.flatMap { two in
group.next().makeSucceededFuture(two + 1)
}.flatMap { three in
group.next().makeSucceededFuture(three + 1)
}.flatMap { four in
group.next().makeSucceededFuture(four + 1)
}.whenSuccess { sum in
group.next().execute {
doIt(allDone: allDone, n: n - 1, accumulator: accumulator + sum)
}
}
}
doIt(allDone: allDone, n: 10_000, accumulator: 0)
print(try allDone.futureResult.wait()) and the results were:
the
the |
Happy to close this. |
Expected behavior
I expect there not to be so many futex calls.
Actual behavior
Steps to reproduce
docker run --security-opt seccomp:unconfined -v$CWD:/code -it --rm swiftnio
cd /code && swift build
strace -s 1024 -fF -tT -o trace.out ./.build/x86_64-unknown-linux/debug/NIOHTTP1Server 0.0.0.0 8888 .
If possible, minimal yet complete reproducer code (or URL to code)
There are no futex calls here:
SwiftNIO version/commit hash
c8d1980
Swift & OS version (output of
swift --version && uname -a
)The text was updated successfully, but these errors were encountered: