From owner-cvs-src@FreeBSD.ORG Sun Jun 18 13:19:06 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD3716A474 for ; Sun, 18 Jun 2006 13:19:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4124F43D49 for ; Sun, 18 Jun 2006 13:19:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35603 invoked from network); 18 Jun 2006 13:18:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Jun 2006 13:18:59 -0000 Message-ID: <449552C9.7060203@freebsd.org> Date: Sun, 18 Jun 2006 15:19:05 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <200606171757.k5HHvahf087725@repoman.freebsd.org> <4494FDF5.1070901@errno.com> <20060618080019.B60374@maildrop.int.zabbadoz.net> In-Reply-To: <20060618080019.B60374@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Leffler , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 13:19:06 -0000 Bjoern A. Zeeb wrote: > On Sun, 18 Jun 2006, Sam Leffler wrote: > >> Andre Oppermann wrote: >>> andre 2006-06-17 17:57:36 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/netinet tcp_var.h >>> Log: >>> Rearrange fields in struct syncache and syncache_head to make them >>> more >>> cache line friendly. >> >> Got any benchmarks to back this up? Or perhaps it was just the smiley >> face your cache lines gave you :) The entry chains are traversed quite often and the first thing looked at is in_conninfo and then sc_rxttime and sc_rxmits. So it makes a lot of sense to have them close together on the same cache line aligned to the beginning of the struct and to the native alignment of the architecture. I did not benchmark it but it is simple reasoning. > That indeed is a good question. From looking at the patch I can see > a new lock introduced while there are other people working on reducing > locking and locking overhead in our network stack trying different > strategies. > > I hadn't seen a patch or any numbers in this months arch@ or net@ > archives (maybe I missed it?). > At the current phase of network stack hacking we should take the > time to get these kind of changes benchmarked under various > loads from different people or at least give them the chance to do > so so nobody can complain afterwards. At least if one wants to > claim performance improvements. Robert Watson and Paul Saab ran the syncache locking changes in their testbeds and found 0.7% and 0% regression. The syncache locking will have its benefits when we deserialize the packet input path. Also the global tcpinfo lock is held for only a very short amount of time instead of the whole time. -- Andre