From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 16:11:15 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5291216A468 for ; Mon, 24 Dec 2007 16:11:15 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D006E13C458 for ; Mon, 24 Dec 2007 16:11:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (c-69-244-251-12.hsd1.fl.comcast.net [69.244.251.12]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBOGB2Hk038170; Mon, 24 Dec 2007 09:11:08 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <476FDA10.4060107@samsco.org> Date: Mon, 24 Dec 2007 11:10:56 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Brett Glass References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> In-Reply-To: <200712241549.IAA19650@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Mon, 24 Dec 2007 09:11:08 -0700 (MST) X-Spam-Status: No, score=2.0 required=5.4 tests=RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 16:11:15 -0000 Brett Glass wrote: > At 07:14 AM 12/24/2007, Scott Long wrote: > >> Brett, >> >> There could be several problems here: >> >> 1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the >> 7.0 snapshots. > > I nuked debugging when I recompiled the kernel with SCHED_ULE. Did you also nuke malloc debugging? > >> 2. Disk subsystem. What kind of disk controller are you using? Not all >> drivers work well in FreeBSD. Are linux and freebsd using identical >> hardware? > > They were. The drives are SATA. Connected to what controller? > >> 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? > > Whatever comes standard with Ubuntu. Which is??? > As for directory hashing: Squid doesn't > use more than 256 entries in each one, so that's what I normally set. I > also normally do a newfs with parameters that favor the distribution of > object sizes found in Web caches. (We did this on both Linux and FreeBSD.) newfs tuning has little to do with this. > >> Would you mind if I logged into your test system and looked around to >> help diagnose the problem? > > The system isn't online now, because it's been a week since the tests and > I also wanted to try the 6.3 beta and a few hardware changes. > > My guess, based on what I saw, is that UFS2 doesn't take as much advantage of > SMP as Linux's file system does and threads are blocking on file I/O. That's really just speculation on your part, though. UFS is SMP capable, but there really are a whole lot of factors that some into play here so it's really hard to speculate with any chance of success. I can tell you from my experience that a thrashed namei cache looks a lot like slow disk I/O to the casual observer, and that tuning the dirhash is highly important. Thus why I'd like to help out here and see for myself what is going on. Scott