Date: Sat, 3 Aug 2002 19:29:57 -0400 From: "Stephane E. Potvin" <sepotvin@videotron.ca> To: freebsd-hackers@FreeBSD.ORG Subject: Re: ARM Port: Help with UMA subsystem needed Message-ID: <20020803192957.D45139@hades.videotron.ca.> In-Reply-To: <20020803154945.B26021-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Sat, Aug 03, 2002 at 03:51:20PM -0400 References: <20020803121419.A35909@unixdaemons.com> <20020803154945.B26021-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 03, 2002 at 03:51:20PM -0400, Jeff Roberson wrote:
>
> 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?
Ok, you'll have to pass me a pointy hat. When I brought back my code back
in sync with current it seems that I overlooked that the pv entries needs
to be allocated with a UMA_ZONE_VM flag. With this I'm now able to boot
up to cpu_thread_setup (which I still need to implement).
Thanks again and sorry for the false alarm
Steph
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?20020803192957.D45139>