On Mon, Jun 17, 2019 at 05:00:32PM -0300, Martin Pieuchot wrote: > On 17/06/19(Mon) 21:43, Claudio Jeker wrote: > > I noticed that by default the send and recv socket buffers for > > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent > > write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and > > SO_RCVBUF seems to help increase the data sent and received per syscall. > > > > Another option would be to make the default socketbuffer watermarks for > > socketpair(2) a bit less limited. Then all imsg users would benefit at the > > same time. > > What's the downside of making the default socketbuffer watermarks > bigger? Wasting resources? How did you figure out that the socket > buffers were too small? Is that something we could apply to other > daemons? >
First about the how I found it. Looking at ktrace output and noticing that write is only pushing 4k of data and read is also only pulling 4k data. Afterwards I used netstat -vP to verify the socketbuffer limits. Bigger watermarks could cause higher pressure on the mbuf/mcluster pools. Now as long as the receiver is processing the data there should not be a problem but once the reader stops more data queues up in the socketbuffer. It would make sense to use something similar to pipe(2)'s method of big and small buffers for socketpair(2). It would also be possible to auto scale the buffers but that is a fair bit harder to implement. I guess a lot of processes could benefit from increased buffers. For example firefox and chrome are heavy users of unix sockets. I remember that we already added something in Xorg to bump the buffer size. A quick check tells me that most unix sockets have sb_hiwat set to 4096. Makes me wonder what the other BSD use for buffer sizes for the different UNIX socket types. -- :wq Claudio
