From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 12:35:20 2007 Return-Path: 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 8E98716A46C; Sun, 2 Dec 2007 12:35:20 +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 67F0213C465; Sun, 2 Dec 2007 12:35:20 +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 D227C46F6E; Sun, 2 Dec 2007 07:39:49 -0500 (EST) Date: Sun, 2 Dec 2007 12:35:12 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <18443.1196596969@critter.freebsd.dk> Message-ID: <20071202123231.G74097@fledge.watson.org> References: <18443.1196596969@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@freebsd.org, Andre Oppermann Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 12:35:20 -0000 On Sun, 2 Dec 2007, Poul-Henning Kamp wrote: > I guess I need to elaborate that point some more: > > If we want CPU affinity, what happens that that we pass a per-cpu timeout > provider: > > timeout_init(&pcpu->timouts, ...) > > If we want a private timeout group for NFS we pass that in: > > timeout_init(&nfs_timeouts, ...) > > Think of the implmentation of the timeouts as an object of which we can have > multiple instances with various private properties... The reason affinity is getting raised in particular is that quite a few people are running around thinking that affinity is something that they do want and plan to use. In the above, affinity is a property of the consumer in the event that the consumer has its own timeout instance. If it's a common property across many consmers, it's not something we want every consumer to deal with as it adds a significant degree of complexity to each consumer. I.e., rather than nfs_timeouts, it's pcpu.nfs_timeouts, or nfs_timeouts[cpu], leading to every consumer defining MAXCPUs or a related constant instances instead of a single instance that knows about affinity. Also, if there are multiple instances, that means "migrating" a callout from one CPU to another involves moving it from one instance to another, rather than simply asking the instance to move it in the way it understands best (which might involve less overhead). Robert N M Watson Computer Laboratory University of Cambridge