From owner-freebsd-arch@FreeBSD.ORG Tue Jan 16 21:10:23 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF31716A58C; Tue, 16 Jan 2007 21:10:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6E46013C4A6; Tue, 16 Jan 2007 21:10:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0GLA1MB047029; Tue, 16 Jan 2007 16:10:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Tue, 16 Jan 2007 16:05:21 -0500 User-Agent: KMail/1.9.1 References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <200701161438.52481.jhb@freebsd.org> <3bbf2fe10701161236s48e6cc16p99c8c38c1d7becde@mail.gmail.com> In-Reply-To: <3bbf2fe10701161236s48e6cc16p99c8c38c1d7becde@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701161605.22394.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 16 Jan 2007 16:10:14 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2457/Tue Jan 16 06:53:04 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs 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: Tue, 16 Jan 2007 21:10:23 -0000 On Tuesday 16 January 2007 15:36, Attilio Rao wrote: > 2007/1/16, John Baldwin : > > On Tuesday 16 January 2007 11:51, Attilio Rao wrote: > > > 2006/7/28, Attilio Rao : > > > > > > > > After some thinking, I think it's better using init/fini methods > > > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > > > > > Feedbacks and comments are welcome: > > > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > > > > > [CC'ed all the interested people] > > > > > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > > > This program claims to reproduce a real httpd server behaviour and is > > > used into the Linux world for benchmarks, AFAIK. > > > I think that results of the comparison on this patch is very > > > interesting, and I think it worths a commit :) > > > I think that results can be even better on a Xeon machine (I had no > > > chance to reproduce this on some of these). > > > (Results taken in consideration have been measured after some starts, > > > in order to minimize caching differences). > > > > > > The patch: > > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > > > Looks good. Some minor nits are that in subr_turnstile.c in the comment I > > would say "a turnstile is allocated" rather than "a turnstile is got from a > > specific UMA zone" as it reads a little bit clearer. Also, I would > > say "Allocate a" rather than "Get a" for the two _alloc() functions. Also, > > why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386 > > and amd64 rather than adding a new UMA_ALIGN_SYNC? > > I was thinking that in this way anyone who wants to replace the > syncronizing primitive boundary to an appropriate value can do it. > I just used UMA_ALIGN_CACHE as default value beacause I don't know the > better boundary (for syncronizing primitives) for other arches. Is there a good reason to not cache-align synch primitives? That is, why would an arch not use cache-align? Also, is there a reason to not update UMA_ALIGN_CACHE on x86? -- John Baldwin