vmem: Fix the gcc build

[markj]

Summary

gcc complains when building libuvmem because the last two operands of ?:
in ORDER2SIZE and SIZE2ORDER have different signs. Add explicit casts
to address this.

Fixes: 1ecf01065b45 ("libuvmem: usermode port of vmem(9)")

[alc]

Since we are starting to expand the usage of vmem, I want to point out something that I only noticed around the time we added support for nextfit allocation. What we call bestfit is really an implementation of firstfit allocation. (A comment pointing this out was actually deleted from the Netbsd original when vmem was imported.) And, what we call firstfit is what, I believe, Solaris calls instantfit. We have no actual implementation of bestfit allocation. That said, mav's long ago change to "create own free list for each of the first 32 possible allocation sizes" has the effect of bestfit allocation for small sizes.

Here is the comment that got deleted:

	} else { /* VM_BESTFIT */
		/*
		 * we assume that, for space efficiency, it's better to
		 * allocate from a smaller block.  thus we will start searching
		 * from the lower-order list than VM_INSTANTFIT.
		 * however, don't bother to find the smallest block in a free
		 * list because the list can be very long.  we can revisit it
		 * if/when it turns out to be a problem.

[markj]

In D54268#1240216, @alc wrote:

Since we are starting to expand the usage of vmem, I want to point out something that I only noticed around the time we added support for nextfit allocation. What we call bestfit is really an implementation of firstfit allocation. (A comment pointing this out was actually deleted from the Netbsd original when vmem was imported.) And, what we call firstfit is what, I believe, Solaris calls instantfit. We have no actual implementation of bestfit allocation. That said, mav's long ago change to "create own free list for each of the first 32 possible allocation sizes" has the effect of bestfit allocation for small sizes.

Here is the comment that got deleted:

	} else { /* VM_BESTFIT */
		/*
		 * we assume that, for space efficiency, it's better to
		 * allocate from a smaller block.  thus we will start searching
		 * from the lower-order list than VM_INSTANTFIT.
		 * however, don't bother to find the smallest block in a free
		 * list because the list can be very long.  we can revisit it
		 * if/when it turns out to be a problem.

If I understand correctly, libuvmem was motivated by a need for an address space allocator for PCI BARs in bhyve. I think a proper M_BESTFIT probably isn't required there, but it might be good to implement one nonetheless. As a first step, perhaps we should restore the naming from Solaris.

[alc]

In D54268#1240309, @markj wrote:

In D54268#1240216, @alc wrote:

Since we are starting to expand the usage of vmem, I want to point out something that I only noticed around the time we added support for nextfit allocation. What we call bestfit is really an implementation of firstfit allocation. (A comment pointing this out was actually deleted from the Netbsd original when vmem was imported.) And, what we call firstfit is what, I believe, Solaris calls instantfit. We have no actual implementation of bestfit allocation. That said, mav's long ago change to "create own free list for each of the first 32 possible allocation sizes" has the effect of bestfit allocation for small sizes.

Here is the comment that got deleted:

	} else { /* VM_BESTFIT */
		/*
		 * we assume that, for space efficiency, it's better to
		 * allocate from a smaller block.  thus we will start searching
		 * from the lower-order list than VM_INSTANTFIT.
		 * however, don't bother to find the smallest block in a free
		 * list because the list can be very long.  we can revisit it
		 * if/when it turns out to be a problem.

If I understand correctly, libuvmem was motivated by a need for an address space allocator for PCI BARs in bhyve. I think a proper M_BESTFIT probably isn't required there, but it might be good to implement one nonetheless. As a first step, perhaps we should restore the naming from Solaris.

In D54268#1240309, @markj wrote:

In D54268#1240216, @alc wrote:

Since we are starting to expand the usage of vmem, I want to point out something that I only noticed around the time we added support for nextfit allocation. What we call bestfit is really an implementation of firstfit allocation. (A comment pointing this out was actually deleted from the Netbsd original when vmem was imported.) And, what we call firstfit is what, I believe, Solaris calls instantfit. We have no actual implementation of bestfit allocation. That said, mav's long ago change to "create own free list for each of the first 32 possible allocation sizes" has the effect of bestfit allocation for small sizes.

Here is the comment that got deleted:

	} else { /* VM_BESTFIT */
		/*
		 * we assume that, for space efficiency, it's better to
		 * allocate from a smaller block.  thus we will start searching
		 * from the lower-order list than VM_INSTANTFIT.
		 * however, don't bother to find the smallest block in a free
		 * list because the list can be very long.  we can revisit it
		 * if/when it turns out to be a problem.

If I understand correctly, libuvmem was motivated by a need for an address space allocator for PCI BARs in bhyve. I think a proper M_BESTFIT probably isn't required there, but it might be good to implement one nonetheless. As a first step, perhaps we should restore the naming from Solaris.

The original vmem paper and NetBSD have instantfit, bestfit, and nextfit. Our import renamed instantfit to firstfit. While the paper never mentioned firstfit, the vmem implementation in a later version of Solaris has it: https://github.com/kofemann/opensolaris/blob/master/usr/src/uts/common/os/vmem.c