Re: fix amd64 pmap comment

2019-11-02 Thread Philip Guenther
On Sat, Nov 2, 2019 at 4:34 AM Martin Pieuchot  wrote:

> uvm_km_alloc(9) has never been used in amd64's pmap.  pool_get(9) is the
> thing since its import by mickey@.
>
> ok?
>

ok guenther@


fix amd64 pmap comment

2019-11-02 Thread Martin Pieuchot
uvm_km_alloc(9) has never been used in amd64's pmap.  pool_get(9) is the
thing since its import by mickey@.

ok?

Index: arch/amd64/amd64/pmap.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.135
diff -u -p -r1.135 pmap.c
--- arch/amd64/amd64/pmap.c 20 Sep 2019 09:38:22 -  1.135
+++ arch/amd64/amd64/pmap.c 2 Nov 2019 12:00:41 -
@@ -180,15 +180,11 @@
  *
  * [A] new process' page directory page (PDP)
  * - plan 1: done at pmap_create() we use
- *   uvm_km_alloc(kernel_map, PAGE_SIZE)  [fka kmem_alloc] to do this
- *   allocation.
+ *   pool_get(_pmap_pool, PR_WAITOK) to do this allocation.
  *
  * if we are low in free physical memory then we sleep in
- * uvm_km_alloc -- in this case this is ok since we are creating
+ * pool_get() -- in this case this is ok since we are creating
  * a new pmap and should not be holding any locks.
- *
- * if the kernel is totally out of virtual space
- * (i.e. uvm_km_alloc returns NULL), then we panic.
  *
  * XXX: the fork code currently has no way to return an "out of
  * memory, try again" error code since uvm_fork [fka vm_fork]