Messages in this thread | | | Subject | Re: ppoll() stuck on POLLIN while TCP peer is sending | From | Eric Dumazet <> | Date | Fri, 04 Jan 2013 09:15:03 -0800 |
| |
On Fri, 2013-01-04 at 16:01 +0000, Mel Gorman wrote:
> Implying that it's stuck in compaction somewhere. It could be the case > that compaction alters timing enough to trigger another bug. You say it > tests differently depending on whether TCP or unix sockets are used > which might indicate multiple problems. However, lets try and see if > compaction is the primary problem or not.
One difference between TCP or unix socket is that :
Unix sockets try hard to limit the order of allocations.
For a 16KB (+ skb overhead) send(), we will probably use one order-2 page and one order-0 page as a frag (data_len being not 0) :
vi +1484 net/unix/af_unix.c
if (len > SKB_MAX_ALLOC) data_len = min_t(size_t, len - SKB_MAX_ALLOC, MAX_SKB_FRAGS * PAGE_SIZE);
skb = sock_alloc_send_pskb(sk, len - data_len, data_len, msg->msg_flags & MSG_DONTWAIT, &err);
While TCP could use order-3 pages if available
Eric, you could try to change SKB_FRAG_PAGE_ORDER in net/core/sock.c to lower values (16384, 8192, 4096) and check if the hang can disappear or not.
Alternatively (no kernel patching needed), you could try to hang AF_UNIX using buffers of 90KB, to force order-3 allocations as well (one 32KB allocation plus 16 * 4KB frags)
Thanks
| |