From owner-freebsd-current@FreeBSD.ORG Wed Aug 3 14:55:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DB9D16A41F for ; Wed, 3 Aug 2005 14:55:20 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C889843D46 for ; Wed, 3 Aug 2005 14:55:19 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 3521 invoked by uid 89); 3 Aug 2005 14:55:53 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 3 Aug 2005 14:55:53 -0000 Received: from 66.166.104.222 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Wed, 3 Aug 2005 08:55:53 -0600 (MDT) Message-ID: <1099.66.166.104.222.1123080953.squirrel@66.166.104.222> In-Reply-To: <20050803071651.A84608@xorpc.icir.org> References: <42F0CCD5.9090200@portaone.com> <20050803071651.A84608@xorpc.icir.org> Date: Wed, 3 Aug 2005 08:55:53 -0600 (MDT) From: "Ryan Sommers" To: "Luigi Rizzo" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: maxim.sobolev@portaone.com, "current@freebsd.org" Subject: Re: Sub-optimal libc's read-ahead buffering behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 14:55:20 -0000 Luigi Rizzo said: > On Wed, Aug 03, 2005 at 04:55:33PM +0300, Maxim Sobolev wrote: >> Hi, >> >> I have found the scenario in which our libc behaves utterly >> suboptimally. Consider the following piece of code reads and processes >> every other 512-bytes block in a file (error handling intentionally > > apparently the issue is in fseek(), you should try to track > why fseeko() it goes to the 'dumb:' label where it simply discards the > buffer and does the seek... > ... other stuff omitted ... Looks like the reason it might go into dumb is because he's using SEEK_SET instead of SEEK_CUR and then hitting: if (!havepos && _ftello(fp, &curoff)) goto dumb; havepos only gets set if the SEEK_CUR switch is hit (oddly enough looks like this could be considered a bug since we are relying on the fact that havepos is zero'd when it is allocated, however, I haven't had ample time to say conclusively). Try using SEEK_CUR and skipping your buffer size each time. -- Ryan Sommers ryans@gamersimpact.com