From owner-freebsd-current Tue Jun 18 22: 7: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CA20C37B415; Tue, 18 Jun 2002 22:06:45 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5J56YP98626; Tue, 18 Jun 2002 23:06:34 -0600 (MDT) (envelope-from ken) Date: Tue, 18 Jun 2002 23:06:34 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020618230634.A98564@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.org> <20020619004313.A29911@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619004313.A29911@unixdaemons.com>; from bmilekic@unixdaemons.com on Wed, Jun 19, 2002 at 12:43:13AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 00:43:13 -0400, Bosko Milekic wrote: > On Tue, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote: > > > > I've released a new zero copy sockets snapshot, against -current from June > > 18th, 2002. > > > > http://people.FreeBSD.org/~ken/zero_copy > > > > The fixes that went into this snapshot: > > > > - Take mutex locking out of ti_attach(), it isn't really needed. > > As long as we can assume that probes of successive ti(4) instances > > happen sequentially, we'll be safe in doing this. Thanks to John > > Baldwin for pointing out the solution to that problem. (The lock in > > ti_attach() was causing all sorts of WITNESS warnings when > > bus_setup_intr() was called.) > > > > - Added a new routine, vm_object_allocate_wait(). This is a variant of > > vm_object_allocate() that allows the user to specify whether the > > uma_zalloc() call inside vm_object_allocate_wait() is called with > > M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when > > jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and > > potentially gives other callers the option of eliminating the mandatory > > wait on the uma_zalloc() call. > > I think this problem was fixed in recent -CURRENT by JeffR. Notably, > the VM system should not allow itself to recurse on itself when called > with M_NOWAIT. A number of problems have been fixed, but I don't think this one would get fixed by internal VM system changes: vm_object_t vm_object_allocate(objtype_t type, vm_size_t size) { vm_object_t result; result = (vm_object_t) uma_zalloc(obj_zone, M_WAITOK); _vm_object_allocate(type, size, result); return (result); } uma_zalloc() is called with M_WAITOK unconditionally. My solution: vm_object_t vm_object_allocate_wait(objtype_t type, vm_size_t size, int flags) { vm_object_t result; result = (vm_object_t) uma_zalloc(obj_zone, flags); if (result != NULL) _vm_object_allocate(type, size, result); return (result); } vm_object_allocate() is implemented by calling vm_object_allocate_wait() with M_WAITOK. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message