with tlb shootdowns disabled, radix scales linearly, and crange has
sub-linear scaling.

with VM_RADIX:

  $ time mapbench 1
  12834002141 cycles
  $ time mapbench 2
  12230873801 cycles
  $ time mapbench 16
  12300269260 cycles

with VM_CRANGE:

  $ time mapbench 1
  12969300915 cycles
  $ time mapbench 2
  15277712346 cycles
  $ time mapbench 16
  58582887683 cycles

tom almost runs xv6 well.  xv6 runs into, what looks like, some APIC
issues.

Some results from mapbench on josmp (with DEBUG 0 and VM_RADIX):

When TLB shootdowns are disabled (comment out tlbflush in vmap::remove),
mapbench is perfectly scalable (perhaps a little slow, but it's hard to
tell, because I didn't used to run with readaccess=1):

  $ time mapbench 1
  12403435727 cycles
  $ time mapbench 2
  12439895511 cycles
  $ time mapbench 16
  12200449501 cycles

With TLB shootdowns, things are slightly less scalable, and significantly
slower:

  $ time mapbench 1
  40044138778 cycles
  $ time mapbench 2
  44034668320 cycles
  $ time mapbench 16
  57569203944 cycles

Lazy TLB shootdowns improve performance on 1 core, and have some but
not nearly perfect scalability:

  $ time mapbench 1
  12658404885 cycles
  $ time mapbench 2
  29790759720 cycles
  $ time mapbench 16
  39160961925 cycles

Next step is to understand why TLB shootdowns are so expensive and how
to make them cheaper/scalable.

as detected by mtrace.

mapbench now has only one real cache line of unexpected sharing:
"name": "tlbflush_req+0x0",

use virtual addresses further away from each other in mapbench,
to avoid contending for radix_node cache lines.

This code is inefficient, it doesn't guarantee to find an unmapped
area if one exists, and it only works for crange.

in terms of performance on real hardware..  need to think more.

to avoid lost tlbflush IPIs.

..allocfd might still cause bottlenecks as threads race to allocate
FD slots..