linux-kernel - Re: Bug 7596 - Potential performance bottleneck for Linxu TCP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061219103756.38f7426c@freekitty>
Date:	Tue, 19 Dec 2006 10:37:56 -0800
From:	Stephen Hemminger <shemminger@...l.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...l.org>, wenji@...l.gov,
	netdev@...r.kernel.org, davem@...emloft.net,
	linux-kernel@...r.kernel.org
Subject: Re: Bug 7596 - Potential performance bottleneck for Linxu TCP

I noticed this bit of discussion in tcp_recvmsg. It implies that a better
queuing policy would be good. But it is confusing English (Alexey?) so
not sure where to start.


> 		if (!sysctl_tcp_low_latency && tp->ucopy.task == user_recv) {
> 			/* Install new reader */
> 			if (!user_recv && !(flags & (MSG_TRUNC | MSG_PEEK))) {
> 				user_recv = current;
> 				tp->ucopy.task = user_recv;
> 				tp->ucopy.iov = msg->msg_iov;
> 			}
> 
> 			tp->ucopy.len = len;
> 
> 			BUG_TRAP(tp->copied_seq == tp->rcv_nxt ||
> 				 (flags & (MSG_PEEK | MSG_TRUNC)));
> 
> 			/* Ugly... If prequeue is not empty, we have to
> 			 * process it before releasing socket, otherwise
> 			 * order will be broken at second iteration.
> 			 * More elegant solution is required!!!
> 			 *
> 			 * Look: we have the following (pseudo)queues:
> 			 *
> 			 * 1. packets in flight
> 			 * 2. backlog
> 			 * 3. prequeue
> 			 * 4. receive_queue
> 			 *
> 			 * Each queue can be processed only if the next ones
> 			 * are empty. At this point we have empty receive_queue.
> 			 * But prequeue _can_ be not empty after 2nd iteration,
> 			 * when we jumped to start of loop because backlog
> 			 * processing added something to receive_queue.
> 			 * We cannot release_sock(), because backlog contains
> 			 * packets arrived _after_ prequeued ones.
> 			 *
> 			 * Shortly, algorithm is clear --- to process all
> 			 * the queues in order. We could make it more directly,
> 			 * requeueing packets from backlog to prequeue, if
> 			 * is not empty. It is more elegant, but eats cycles,
> 			 * unfortunately.
> 			 */
> 			if (!skb_queue_empty(&tp->ucopy.prequeue))
> 				goto do_prequeue;
> 
> 			/* __ Set realtime policy in scheduler __ */
> 		}
> 
> 		if (copied >= target) {
> 			/* Do not sleep, just process backlog. */
> 			release_sock(sk);
> 			lock_sock(sk);
> 		} else
> 		

-- 
Stephen Hemminger <shemminger@...l.org>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/