From owner-freebsd-arch@FreeBSD.ORG  Sun Oct 21 13:00:03 2007
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A519116A41A
	for <arch@FreeBSD.org>; Sun, 21 Oct 2007 13:00:03 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 4014813C48D
	for <arch@FreeBSD.org>; Sun, 21 Oct 2007 12:58:53 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
	by cyrus.watson.org (Postfix) with ESMTP id E5E3048D39
	for <arch@FreeBSD.org>; Sun, 21 Oct 2007 08:57:51 -0400 (EDT)
Date: Sun, 21 Oct 2007 13:57:51 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: arch@FreeBSD.org
In-Reply-To: <20071020184330.C70919@fledge.watson.org>
Message-ID: <20071021135243.M70919@fledge.watson.org>
References: <20071020184330.C70919@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: 
Subject: Re: Lock profiling results on TCP and an 8.x project
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Oct 2007 13:00:03 -0000

On Sat, 20 Oct 2007, Robert Watson wrote:

> * When talking about percentage of available CPUs, I make the assumption 
> that
>  due to a sufficient quantity of CPUs, in most cases lock acquisition will
>  occur as a result of adaptive spinning rather than sleeping.  In the 
> netperf
>  case, this is not true, since the number of potential workers exceeds the
>  number of CPUs, hence the turnstile contention.  However, as sleeping on
>  locks itself is very expensive, it's reasonable to assume we would recover
>  a lot of CPU none-the-less.

FYI, a feature request for lock profiling: it would be nice if we also tracked 
for each contention point time spent spinning vs. context switched waiting for 
the lock, and the number of context switches the lock acquisition point has 
caused.  This would allow us to better understand the impact of adaptive lock 
behavior for workloads and configurations.

Robert N M Watson
Computer Laboratory
University of Cambridge