From owner-freebsd-fs@FreeBSD.ORG Thu Apr 17 04:45:38 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CB9637B401; Thu, 17 Apr 2003 04:45:38 -0700 (PDT) Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0481F43FAF; Thu, 17 Apr 2003 04:45:37 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (unknown [161.53.19.14]) by premijer.tel.fer.hr (Postfix) with ESMTP id 120DA1380; Thu, 17 Apr 2003 13:45:17 +0200 (MET DST) Message-ID: <3E9E93D8.EB16ED42@tel.fer.hr> Date: Thu, 17 Apr 2003 13:45:28 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030414101935.GB18110@HAL9000.homeunix.com> <3E9C5975.43755858@tel.fer.hr> <20030416101136.GA868@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-fs@FreeBSD.org cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 11:45:38 -0000 David Schultz wrote: > On Tue, Apr 15, 2003, Marko Zec wrote: > > > > > - The fiddling with rushjob seems rather arbitrary. You can probably > > > just let the existing code increment it as necessary and force a sync > > > if the value gets too high. > > > > If rushjob is would not be used for forcing prompt synching, the original code > > could not guarantee the sync to occur immediately. Instead, the synching could > > be further delayed for up to 30 seconds, which is not desirable if our major > > design goal is to do as much disk I/O as possible in a small time interval and > > leave the disk idle otherwise. > > I was referring to all the places where rushjob is set to or > incremented by syncer_maxdelay. AFAIK, it should never be that > large. Hmm... Why? :) > I don't think you want to overload a low memory handling > mechanism with the task of syncing the disk. As far as I can see the rushjob variable is used only at one place in kern/vfs_subr.c to notify softupdates synching scheduler to start synching earlier than the normal timers would expire. I just reused the same mechanism to urge synching of dirty buffers when the extra delay timer expires, or when outstanding disk I/O occurs, to coalesce disk updates with occasional disk spinups. Marko