Date: Tue, 18 Jun 2002 23:06:34 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020618230634.A98564@panzer.kdm.org> In-Reply-To: <20020619004313.A29911@unixdaemons.com>; from bmilekic@unixdaemons.com on Wed, Jun 19, 2002 at 12:43:13AM -0400 References: <20020618223635.A98350@panzer.kdm.org> <20020619004313.A29911@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020618230634.A98564>