On Fri, 13.12.13 22:16, Karol Lewandowski (lmc...@gmail.com) wrote: > > On Fri, Dec 13, 2013 at 03:45:36PM +0100, Lennart Poettering wrote: > > On Fri, 13.12.13 12:46, Karol Lewandowski (k.lewando...@samsung.com) wrote: > > > Well, are you suggesting that the AF_UNIX/SOCK_DGRAM code actually hands > > off the timeslice to the other side as soon as it queued something in? > > If by other side you mean receiving one, then no - qnx seems to do > that, but it isn't the case here. What I'm trying to say here is that > kernel puts the process doing send(2) into sleep when (a) queue fills > up and (b) fd is blocking one (otherwise we just get EAGAIN). That's > expected, I presume. > > One of the problems I see, though, is that no matter how deep I make > the queue (`max_dgram_qlen') I still see process sleeping on send() > way earlier that configured queue depth would suggest.
It would be interesting to find out why this happens. I mean, there are three parameters here I could think of that matter: the qlen, SO_SNDBUF on the sender, and SO_RCVBUF on the receiver (though the latter two might actually change the same value on AF_UNIX? or maybe one of the latter two is a NOP on AF_UNIX?). If any of them reaches the limit then the sender will necessarily have to block. (SO_SNDBUF and SO_RCVBUF can also be controlled via /proc/sys/net/core/rmem* and ../wmem*... For testing purposes it might be easier to play around with these and set them to ludicrously high values...) I mean, this appears to be the crux here: this blocks too early but it really shouldn't block at all. we should find the reason for this and fix it. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
