On Wed, 2015-11-25 at 20:57 +0000, Rainer Weikusat wrote: > I do agree that keeping the ->sk_data_ready outside of the lock will > very likely have performance advantages. That's just something I > wouldn't have undertaken because I'd be reluctant to make a fairly > complicated change to a lot of code.
All I am saying is that we can keep current performance. We already have the core infrastructure, we only need to properly use it. I will split my changes in two parts. One part doing a very boring change of rename SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA for X in SOCK_ASYNC_NOSPACE SOCK_ASYNC_WAITDATA set_bit(X, &sk->sk_socket->flags) -> sk_set_bit(X, sk) clear_bit(X, &sk->sk_socket->flags) -> sk_clear_bit(X, sk) The rename will help backports to catch code that might have been removed in recent kernels. Then the second patch will do the actual changes, and they will look very sensible for people wanting to review them, and or familiar with the stack, do not worry ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
