Date: Thu, 2 Apr 2009 11:52:36 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: =?ISO-2022-JP?Q?=1B$BVC4d=1B=28Jccuiyyan=40sina=2Ecom?= <ccuiyyan@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: dup() scales badly on multicore platform Message-ID: <alpine.BSF.2.00.0904021151320.94891@fledge.watson.org> In-Reply-To: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> References: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904021151320.94891>