From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 18:34:46 2004 Return-Path: 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 4B35B16A4CE for ; Sat, 4 Sep 2004 18:34:46 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D8843D1F for ; Sat, 4 Sep 2004 18:34:45 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i84IYVrk032267; Sat, 4 Sep 2004 11:34:35 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409041834.i84IYVrk032267@gw.catspoiler.org> Date: Sat, 4 Sep 2004 11:34:31 -0700 (PDT) From: Don Lewis To: dillon@apollo.backplane.com In-Reply-To: <200409041723.i84HNi4Q046252@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 04 Sep 2004 18:34:46 -0000 On 4 Sep, Matthew Dillon wrote: > :This sort of thing was my initial thought, but the posted CPU usage > :statistics show that fsck is burning up most of its CPU cycles in > :userland. > : > :>> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > : > :Increasing MAXBUFSPACE looks like it would make the problem worse > :because getdatablk() does a linear search. > > Oh my. I didn't even notice. That code dates all the way back to 1994 > so I wont bash the author too badly, but it is pretty aweful coding. At least it moves the buffer to the front of the list so that repeated accesses of the same buffer are fast. > Hashing the buffer cache is trivial. I'll do it for DragonFly and post > the patch as a template for you guys to do it in FreeBSD (or you could just > do it on your own, it really does look trivial). You might want to instrument the code to find out how much reuse there is of the cached data. I would not expect much reuse within a pass, which may mean that increasing MAXBUFSPACE might not help much. Doing read-ahead might help, especially if it can be hinted (do read-ahead when reading inode blocks but not indirect blocks). The read-ahead already done by the drive gets rid of the latency caused by mechanical issues, but explicitly doing read-ahead in the fsck code would eliminate some kernel overhead and drive command latency. As I mentioned before, profiling the code is likely to be interesting.