Improving fget() performance [LWN.net]

Improving fget() performance

Posted May 6, 2019 22:27 UTC (Mon) by djwatson24 (guest, #74976)
In reply to: Improving fget() performance by roc
Parent article: Improving fget() performance

One complication is that often one thread accepts, but then is load balanced to another thread for most of its lifetime. So it may be necessary to somehow specify or change the fd range at a time later than accept() or open().

Improving fget() performance

Posted May 7, 2019 6:40 UTC (Tue) by smurf (subscriber, #17840) [Link] (3 responses)

I'd suggest that the only tasks where sequential allocation matters is when you close fd 0…2 right before dup()ing, and even that is highly unreliable in a threaded environment (thread 1 closes stdout, thread 2 calls accept(), thread 1 dup()s … oops – should have used dup2() …).

Thus, sequential allocation doesn't need a flag or its absence, it only needs to check that the refcount of the fd table is ==1.

Improving fget() performance

Posted May 7, 2019 17:24 UTC (Tue) by willy (subscriber, #9762) [Link] (2 responses)

It is mandated POSIX behaviour though, so we usually like to have a way for applications to opt-in to non-POSIX behaviour, be it a prctl, an fcntl or something else.

Let's see what the dup2() experiment buys us, then we can discuss how to implement it (if it is a win)

Improving fget() performance

Posted May 7, 2019 19:55 UTC (Tue) by abatters (✭ supporter ✭, #6932) [Link] (1 responses)

Instead of using non-sequential fds, how about indexing the table differently by shuffling the bits of the fd around before using it as an index, so that sequential fds don't share a cacheline?

Improving fget() performance

Posted May 7, 2019 20:11 UTC (Tue) by willy (subscriber, #9762) [Link]

Nice idea. Unfortunately, the problem is not that fds are assigned to threads in some kind of round-robin order. They're assigned to threads in a semi-random order in an attempt to keep worker threads equally busy. Adding in a shuffle isn't going to help.