From: Al Viro <v...@zeniv.linux.org.uk> Date: Sun, 5 May 2019 18:59:43 +0100
> On Sun, May 05, 2019 at 10:04:21AM -0700, David Miller wrote: >> From: Al Viro <v...@zeniv.linux.org.uk> >> Date: Thu, 2 May 2019 17:32:23 +0100 >> >> > it appears that we might take freeing the socket itself to the >> > RCU-delayed part, along with socket->wq. And doing that has >> > an interesting benefit - the only reason to do two separate >> > allocation disappears. >> >> I'm pretty sure we looked into RCU freeing the socket in the >> past but ended up not doing so. >> >> I think it had to do with the latency in releasing sock related >> objects. >> >> However, I might be confusing "struct socket" with "struct sock" > > Erm... the only object with changed release time is the memory > occupied by struct sock_alloc. Currently: > final iput of socket > schedule RCU-delayed kfree() of socket->wq > kfree() of socket > With this change: > final iput of socket > schedule RCU-delayed kfree() of coallocated socket and socket->wq > > So it would have to be a workload where tons of sockets are created and > torn down, where RCU-delayed freeing of socket_wq is an inevitable evil, > but freeing struct socket_alloc itself must be done immediately, to > reduce the memory pressure. Or am I misreading you? I think I was remembering trying to RCU "struct sock" release because those 'sk' refer to SKBs and stuff like that. So, what you are proposing looks fine.
