From owner-cvs-src@FreeBSD.ORG Fri Mar 31 16:31:10 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0A4316A41F; Fri, 31 Mar 2006 16:31:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B64243D48; Fri, 31 Mar 2006 16:31:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 15E5146BDA; Fri, 31 Mar 2006 11:31:10 -0500 (EST) Date: Fri, 31 Mar 2006 16:31:10 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20060331162815.5qhte5ct4co4o0ww@netchild.homeip.net> Message-ID: <20060331162807.K88223@fledge.watson.org> References: <2893454.4353801143813632253.JavaMail.root@vms169.mailsrvcs.net> <20060331162815.5qhte5ct4co4o0ww@netchild.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joao Barros , src-committers@FreeBSD.org, Peter Jeremy , "Christian S.J. Peron" , cvs-all@FreeBSD.org, babkin@users.sourceforge.net, cvs-src@FreeBSD.org Subject: Re: Re: cvs commit: src/usr.sbin/syslogd syslogd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 16:31:11 -0000 On Fri, 31 Mar 2006, Alexander Leidinger wrote: >>> Do you know if a kqueue based solution is cheaper? >> >> Probably should not matter. Syslog writes data to disk synchronously, >> right? So anything not involving a disk access is negligible in cost >> compared to the main action of writing the log entry. > > Regarding syslogd: yes. Regarding the overal system: maybe. Regarding an > overloaded server: every cycle matters. > > When you can get the same (features, quality, nice design, ...) cheaper, why > not choose the cheaper one? I don't ask for premature optimization, I just > ask for not bloating something in the first place (if the difference in the > amount of work is small). I think you'll find the cost of an fstatfs() call is so low that the cost of setting up monitoring is appreciably similar. I think the right thing to do, if worried, is to prototype the architecturally simple solution, and then see if there's a problem. Premature optimization is what happens when you complicate software in order to solve a performance problem that doesn't exist, possibly resulting in slower software, and certainly resulting in harder to maintain software. :-) I'm pretty sure you'll find that the cost of fstatfs() is basically unmeasurable in this context. Robert N M Watson