Improving fget() performance [LWN.net]

Improving fget() performance

Posted May 7, 2019 6:40 UTC (Tue) by smurf (subscriber, #17840)
In reply to: Improving fget() performance by djwatson24
Parent article: Improving fget() performance

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.

to post comments

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.