Looks reasonable to me. I once modified the NFS code to use page_size clusters
for larger RPC messages and it could get hung when 4K clusters were exhausted.
--> I never though to do the 4K clusters with M_NOWAIT and then fallback to

regular clusters.

This patch looks fine to me. (I'll let you decide if markj@'s suggested changes
make the code more readable?)

Is there a possible side effect where if we now never do an M_WAITOK
alloc from zone_jumbop then we may not increase the zone size up to the
limit? As in, should there be a condition in here where we only convert
M_WAITOK to M_NOWAIT if we are actually near the limit? For example
should mb_reclaim arm this?

In D26150#584330, @rlibby wrote:

Is there a possible side effect where if we now never do an M_WAITOK
alloc from zone_jumbop then we may not increase the zone size up to the
limit? As in, should there be a condition in here where we only convert
M_WAITOK to M_NOWAIT if we are actually near the limit? For example
should mb_reclaim arm this?

I'm woefully ignorant of how UMA manages things, and had not realized that this would cause the zone to be more limited.

Mark, what do you think?

In D26150#584330, @rlibby wrote:

Is there a possible side effect where if we now never do an M_WAITOK
alloc from zone_jumbop then we may not increase the zone size up to the
limit?

You mean, because of a memory shortage? In a scenario where we are persistently failing to allocate slabs for UMA I'm not sure that it's very important to prioritize allocation from a specific zone. Maybe I'm misunderstanding?

As in, should there be a condition in here where we only convert
M_WAITOK to M_NOWAIT if we are actually near the limit? For example
should mb_reclaim arm this?

It sounds like you are suggesting a new semantic: sleep during memory shortages, but bail without sleeping if the zone limit is reached. That seems easiest to accomplish with a new malloc flag.