From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:52:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E18C1065675 for ; Thu, 2 Apr 2009 10:52:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C717F8FC13 for ; Thu, 2 Apr 2009 10:52:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 528E746B51; Thu, 2 Apr 2009 06:52:36 -0400 (EDT) Date: Thu, 2 Apr 2009 11:52:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-2022-JP?Q?=1B$BVC4d=1B=28Jccuiyyan=40sina=2Ecom?= In-Reply-To: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> Message-ID: References: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-14832556-1238669556=:94891" Cc: freebsd-current@freebsd.org Subject: Re: dup() scales badly on multicore platform X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 10:52:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-14832556-1238669556=:94891 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed On Thu, 2 Apr 2009, 崔岩ccuiyyan@sina.com wrote: > i benchchmark the dup() system call on 32 cores machine in > FreeBSD-current8.0. > > The results are bad. The phenomenon is easy to come out. Each > process(not thread) on the core > > dup() its private file, and close() in a tight loop. The time > completing the parallel workload > > is considered as performance. At first, i think there are some locks. > However, lock profiling > > in FreeBSD is strange and interesting. I attach the graph and lock > profiling. Any ideas? Could you post your benchmark code? It sounds from the above as though you have 32 processes, ecah dup'ing and closing a descriptor originally created in that process (and not a shared descriptor with other processes)? Robert N M Watson Computer Laboratory University of Cambridge --621616949-14832556-1238669556=:94891--