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
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
