Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Aug 2002 15:51:20 -0400 (EDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        "Stephane E. Potvin" <sepotvin@videotron.ca>, <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: ARM Port: Help with UMA subsystem needed
Message-ID:  <20020803154945.B26021-100000@mail.chesapeake.net>
In-Reply-To: <20020803121419.A35909@unixdaemons.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, 3 Aug 2002, Bosko Milekic wrote:

>
> On Sat, Aug 03, 2002 at 11:07:11AM -0400, Stephane E. Potvin wrote:
> >
> > I just found out that reverting this commit fixes the problem. Any
> > ideas about why other arches don't encouter the problem?
> >
> > jeff        2002/06/19 13:49:44 PDT
> >
> >   Modified files:
> >     sys/vm               uma.h uma_core.c
> >   Log:
> >   - Remove bogus use of kmem_alloc that was inherited from the old zone
> >     allocator.
>
>    This looks like the problem, or at least that which uncovers the
>    problem.  The pmap code is calling the zone allocator as well and
>    what happens is that you recurse on the kmem_map lockmgr lock because
>    you allocate recursively from kmem_map.  Previously, we could also
>    allocate from kernel_map, if the kernel_map lockmgr lock wasn't held,
>    so this way if we had a recursive call we would get around this
>    problem.  I think this whole thing is flaky in general (if this was
>    the way to get around recursion, we should fix it).
>
>    JHB and/or JeffR: why is the kmem_map lockmgr lock not recursive?
>

These locks can not be made recurisve safely.  In this case you would just
recurse forever and never satisfy the allocation.  All pmap modules do
something like the following:

static void *
pmap_allocf(uma_zone_t zone, int bytes, u_int8_t *flags, int wait)
{
        *flags = UMA_SLAB_PRIV;
        return (void *)kmem_alloc(kernel_map, bytes);
}

        pvzone = uma_zcreate("PV ENTRY", sizeof (struct pv_entry), NULL,
NULL,
            NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM);
        uma_zone_set_allocf(pvzone, pmap_allocf);
        uma_prealloc(pvzone, initial_pvs);


Is arm using a seperate allocf?

Jeff


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020803154945.B26021-100000>