From owner-freebsd-questions@FreeBSD.ORG Sat May 30 11:35:04 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE3A1065670 for ; Sat, 30 May 2009 11:35:04 +0000 (UTC) (envelope-from mel.flynn+fbsd.questions@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id DF7448FC14 for ; Sat, 30 May 2009 11:35:03 +0000 (UTC) (envelope-from mel.flynn+fbsd.questions@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id A984C7E837; Sat, 30 May 2009 03:35:02 -0800 (AKDT) From: Mel Flynn To: freebsd-questions@freebsd.org Date: Sat, 30 May 2009 13:35:00 +0200 User-Agent: KMail/1.11.3 (FreeBSD/8.0-CURRENT; KDE/4.2.3; i386; ; ) References: <89C182FE-81B9-474E-84EA-FBB6F68C4E75@eecs.berkeley.edu> <9DCE53EA-E680-48C3-BF7F-A5AAC656EB6D@eecs.berkeley.edu> In-Reply-To: <9DCE53EA-E680-48C3-BF7F-A5AAC656EB6D@eecs.berkeley.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905301335.00950.mel.flynn+fbsd.questions@mailing.thruhere.net> Cc: Steven Schlansker Subject: Re: pfsync in GENERIC? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 11:35:04 -0000 On Saturday 30 May 2009 05:13:27 Steven Schlansker wrote: > On May 29, 2009, at 5:29 PM, Michael Powell wrote: > > Steven Schlansker wrote: > > > > [snip] > > > > A custom kernel can free up a little RAM, and maybe boot a little > > sooner, > > but it won't produce any earth shattering differences. I think most > > do it to > > 'shrink' down and eliminate anything which is not required for a > > particular > > piece of hardware. It decreases the possibility of something unneeded > > causing a problem, and enhances problem resolution by making the > > list of > > potential culprits smaller. > > Yeah, that's basically how I felt as well. However as to the > "something unneeded causing a problem" I must say I've never had a > GENERIC kernel fail due to some unneeded device driver, but I've > definitely had a custom built kernel fail because of some tunable or > driver I misconfigured! The general consensus is shifting indeed, as hardware makes more and bigger leaps then software. However, you will not notice a trimmed kernel's performance "under standard workload", but will be able to squeeze more out of the box under extreme loads, due to the simple fact that the kernel has more memory to work with. Also, there are still a few tunables left that can only be set at compile time, MAXPHYS being the most prominent that comes to mind. -- Mel