From owner-cvs-all  Wed Dec 13  0:54:25 2000
From owner-cvs-all@FreeBSD.ORG  Wed Dec 13 00:54:20 2000
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 928E537B402; Wed, 13 Dec 2000 00:54:20 -0800 (PST)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id eBD8sK413200;
	Wed, 13 Dec 2000 00:54:20 -0800 (PST)
Date: Wed, 13 Dec 2000 00:54:20 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Kirk McKusick <mckusick@FreeBSD.org>
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/ufs/ffs ffs_inode.c ffs_softdep.c src/sys/ufs/ufs ufs_extern.h ufs_lookup.c
Message-ID: <20001213005420.Z16205@fw.wintelcom.net>
References: <200012130830.eBD8UbJ17674@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200012130830.eBD8UbJ17674@freefall.freebsd.org>; from mckusick@FreeBSD.org on Wed, Dec 13, 2000 at 12:30:37AM -0800
Sender: bright@fw.wintelcom.net
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Kirk McKusick <mckusick@FreeBSD.org> [001213 00:30] wrote:
> mckusick    2000/12/13 00:30:37 PST
> 
>   Modified files:
>     sys/ufs/ffs          ffs_inode.c ffs_softdep.c 
>     sys/ufs/ufs          ufs_extern.h ufs_lookup.c 
>   Log:
>   Preventing runaway kernel soft updates memory, take three.
>   Previously, the syncer process was the only process in the
>   system that could process the soft updates background work
>   list. If enough other processes were adding requests to that
>   list, it would eventually grow without bound. Because some of
>   the work list requests require vnodes to be locked, it was
>   not generally safe to let random processes process the work
>   list while they already held vnodes locked. By adding a flag
>   to the work list queue processing function to indicate whether
>   the calling process could safely lock vnodes, it becomes possible
>   to co-opt other processes into helping out with the work list.
>   Now when the worklist gets too large, other processes can safely
>   help out by picking off those work requests that can be handled
>   without locking a vnode, leaving only the small number of
>   requests requiring a vnode lock for the syncer process. With
>   this change, it appears possible to keep even the nastiest
>   workloads under control.

Possible, but this doesn't seem like it will always do the
job.  Why not implement a max amount of requests and block
processes who want to add until the threshhold goes below
some mark?

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message