From owner-freebsd-arch Tue Feb 11 3:57:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDAB437B401 for ; Tue, 11 Feb 2003 03:57:28 -0800 (PST) Received: from flaske.stud.ntnu.no (flaske.stud.ntnu.no [129.241.56.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0844543FB1 for ; Tue, 11 Feb 2003 03:57:28 -0800 (PST) (envelope-from morten@rodal.no) Received: from localhost (localhost [127.0.0.1]) by flaske.stud.ntnu.no (Postfix) with ESMTP id A41A8FF423; Tue, 11 Feb 2003 12:57:26 +0100 (CET) Received: from slurp.rodal.no (m200h.studby.ntnu.no [129.241.135.200]) by flaske.stud.ntnu.no (Postfix) with ESMTP id EC402FF3CB; Tue, 11 Feb 2003 12:57:25 +0100 (CET) Received: (from morten@localhost) by slurp.rodal.no (8.12.6/8.12.6/Submit) id h1BBvMqP000757; Tue, 11 Feb 2003 12:57:22 +0100 (CET) (envelope-from morten) Date: Tue, 11 Feb 2003 12:57:22 +0100 From: Morten Rodal To: Alfred Perlstein Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: Our lemming-syncer caught in the act. Message-ID: <20030211115722.GA716@slurp.rodal.no> References: <20030210091317.GD5165@HAL9000.homeunix.com> <37473.1044868995@critter.freebsd.dk> <20030210204523.GF12240@slurp.rodal.no> <20030210205443.GA88781@elvis.mu.org> <200302102225.h1AMPkTE023700@apollo.backplane.com> <20030210223904.GG88781@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030210223904.GG88781@elvis.mu.org> X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 10, 2003 at 02:39:04PM -0800, Alfred Perlstein wrote: > * Matthew Dillon [030210 14:25] wrote: > > > > Try reproducing the problem with kernel profiling turned on. The > > syncer is not likely to be the cause of the large file removal issue, > > since that involves only bitmaps. The cause is more likely to be > > softupdate's bitmap dependancies. Try turning off softupdates and see > > if that improves performance. Softupdates creates some rather nasty > > buffer cache issues due to the number of buffers it removes from > > management. Also, dependancies prevent the buffer cache from being > > able to flush a buffer. The buffer cache was not really designed to > > deal with flushes which don't undirty a buffer or large numbers of > > buffers being temporarily removed from management. > > Profiling sounds like a good idea, but I have never even done profiling on a regular program so I think I'll wait a little before I try something like that on the kernel. Unfortunatly I will not be able to test the performance without softupdates right now, and I forgot to look at that when I tested Alfred's patch. > I don't have a 5.x box handy here, but if someone could run this patch > and let me know what it does I would appreciate it. > > cd /usr/src/sys/kern && patch < path_to_this_file > [snip patch] The patch did not solve the problem. At first I only tried with the last giant pre-emptive, but found out the problem were still there. I then enabled the ifdef (to be presise I removed it), but it did not seem to make any difference at all. -- Morten Rodal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message