At this stage we can actually avoid grabbing the lock in the default
pool backend allocator, as long as the PR_WAITOK flag isn't set. This
is safe because:
* The pmemrange allocator can be called without holding the kernel
lock.
* On pmap_direct architectures, we simply use the direct map to access
the allocated physical page.
* On non-pmap_direct architectures, we grab a free virtual page from a
list that is properly protected by a mutex. The page is then mapped
using pmap_kenter_pa() and unmapped pmap_remove(). These function
are safe on i386 and sparc64. There currently are no other
non-pmap_direct architectures that have a GENERIC.MP kernel.
ok?
Index: subr_pool.c
===================================================================
RCS file: /cvs/src/sys/kern/subr_pool.c,v
retrieving revision 1.189
diff -u -p -r1.189 subr_pool.c
--- subr_pool.c 1 Sep 2015 08:22:45 -0000 1.189
+++ subr_pool.c 4 Sep 2015 20:08:10 -0000
@@ -1436,9 +1436,17 @@ pool_page_alloc(struct pool *pp, int fla
kd.kd_waitok = ISSET(flags, PR_WAITOK);
kd.kd_slowdown = slowdown;
- KERNEL_LOCK();
+ /*
+ * XXX Until we can call msleep(9) without holding the kernel
+ * lock.
+ */
+ if (ISSET(flags, PR_WAITOK))
+ KERNEL_LOCK();
+
v = km_alloc(pp->pr_pgsize, &kv_page, pp->pr_crange, &kd);
- KERNEL_UNLOCK();
+
+ if (ISSET(flags, PR_WAITOK))
+ KERNEL_UNLOCK();
return (v);
}
