From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 28 01:15:47 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49D216A41A for ; Wed, 28 Nov 2007 01:15:47 +0000 (UTC) (envelope-from binto@triplegate.net.id) Received: from asterix-2.3gate.net (asterix-2.3gate.net [202.127.97.37]) by mx1.freebsd.org (Postfix) with SMTP id DD23F13C43E for ; Wed, 28 Nov 2007 01:15:46 +0000 (UTC) (envelope-from binto@triplegate.net.id) Received: (qmail 45718 invoked by uid 1011); 28 Nov 2007 01:09:11 -0000 Received: from 202.127.97.100 by asterix-2.3gate.net (envelope-from , uid 1009) with qmail-scanner-1.25-st-qms (clamdscan: 0.91.2/4619. perlscan: 1.25-st-qms. Clear:RC:1(202.127.97.100):. Processed in 0.023282 secs); 28 Nov 2007 01:09:11 -0000 X-Antivirus-MY_3GNET-Mail-From: binto@triplegate.net.id via asterix-2.3gate.net X-Antivirus-MY_3GNET: 1.25-st-qms (Clear:RC:1(202.127.97.100):. Processed in 0.023282 secs Process 45712) Received: from smtp.triplegate.net.id (HELO lb1.3gate.net) (202.127.97.100) by asterix-2.3gate.net with SMTP; 28 Nov 2007 01:09:11 -0000 Received: from webmail.triplegate.net.id (unknown [202.127.97.10]) by lb1.3gate.net (Postfix) with ESMTP id 013B4211018; Wed, 28 Nov 2007 08:12:41 +0700 (WIT) Received: from 202.127.98.144 (SquirrelMail authenticated user binto@triplegate.net.id) by webmail.triplegate.net.id with HTTP; Wed, 28 Nov 2007 08:19:58 +0700 (WIT) Message-ID: <2757.202.127.98.144.1196212798.squirrel@webmail.triplegate.net.id> In-Reply-To: <474A17DE.7010804@FreeBSD.org> References: <474830F9.90305@zirakzigil.org> <6eb82e0711240638g2cc1e54o1fb1321cafe8ff9f@mail.gmail.com> <1188.202.127.99.4.1195957922.squirrel@webmail.triplegate.net.id> <20071125110116.U63238@fledge.watson.org> <20071125143546.V6583@cauchy.math.missouri.edu> <20071125211807.GA12250@freebsd.org> <474A17DE.7010804@FreeBSD.org> Date: Wed, 28 Nov 2007 08:19:58 +0700 (WIT) From: "binto" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: binto , Roman Divacky , Robert Watson Subject: Re: Before & After Under The Giant Lock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2007 01:15:47 -0000 Hi, Thanks for all response, especially for Mr. Robert N M Watson I read all , and i got a lot thing from conversation about this. It's nice community, thanks once again. Regards Binto > Roman Divacky wrote: >> On Sun, Nov 25, 2007 at 02:41:35PM -0600, Stephen Montgomery-Smith >> wrote: >>> >>> On Sun, 25 Nov 2007, Robert Watson wrote: >>> >>>> ........................ >>>> In FreeBSD 8, I expect we'll see a continued focus on both locking >>>> granularity and improving opportunities for kernel parallelism by >>>> better >>>> distributing workloads over CPU pools. This is important because the >>>> number of cores/chip is continuing to increase dramatically, so MP >>>> performance is going to be important to keep working on. That said, >>>> the >>>> results to date have been extremely promising, and I anticipate that >>>> we >>>> will continue to find ways to better exploit multiprocessor hardware, >>>> especially in the network stack. >>>> >>> I just want to add my 2 cents, that my recent experience with FreeBSD >>> MP >>> has been extremely positive. I tend to use highly CPU bound MP >>> programs, >>> typically lots and lots of floating point operations. It used to be >>> that >>> Linux beat FreeBSD hands down - now FreeBSD seems to have a slight >>> edge! >>> Basically my program runs about twice as fast when I run two threads as >>> opposed to one - I cannot see doing any better than that! >> >> pure computation does not need kernel operations most of the time.. ie. >> multi-threading kernel wont help much ;) > > It has an indirect benefit by (presumably) not being in contention > with the userland process, and not needing slap Giant on the whole > system every few milliseconds. > > Doug > > -- > > This .signature sanitized for your protection > >