From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 12:01:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B15616A41F; Fri, 28 Oct 2005 12:01:42 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B7643D53; Fri, 28 Oct 2005 12:01:41 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms062.mailsrvcs.net ([192.168.1.3]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IP200I05K2T8C20@vms042.mailsrvcs.net>; Fri, 28 Oct 2005 07:01:41 -0500 (CDT) Date: Fri, 28 Oct 2005 07:01:41 -0500 (CDT) From: Sergey Babkin To: Vaibhave Agarwal Message-id: <20858923.1130500901324.JavaMail.root@vms062.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 28 Oct 2005 13:18:07 +0000 Cc: freebsd , freebsd Subject: Re: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 12:01:42 -0000 >From: Robert Watson >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > >> How do u disable malloc debugging flags in the userland? I read >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. >> How does it work? >> >> And how to disable verbose features in the kernel? >> >> Apart from this, are there other ways to make the kernel run faster?? > >Other than that, you'll need to tell us what you're doing. And the most important part: try to optimize your application first. I've seen a surprizing number of people who feel that they need to do something with the kernel while what is really suboptimal (or downright broken) is their application. When writing programs people make many assumptions about what is fast and often these assumptions are wrong, plus there are bugs where the code generally works but does it slowly. This is especially true for applications written in C++ and other OO languages, and for threaded applications. If you want to have a cost-efficient solution, the applications really need to be profiled and measured, and all the performance squeezed out of them before going into the kernel. -SB