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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
