A possibly unintended consequence of the kernel's alloc_bounce_zone implementation?

I was doing some exploratory investigation of getting a "C0T"
RPi4B that does not have the PCIe block wrapper logic messed
up --in order to avoid much of the bounce zone usage that adds
to the challenged memory/RAM-caching subsystem involved. I
ended up noticing an odd property of the alloc_bounce_zone
implementation when I tried to have a larger hw.busdma zone
show up. (This was before trying to get beyond 4 GiBytes.)

To simplify the description below, I use examples of extreme
conditions that are simple to describe.

A)	Presume that the sequence of calls to alloc_bounce_zone
	never had an incompatible alignment. (dmat->lowaddr is
	the point here.)

B)	Concentrate on two ordering properties across the calls:

B1)	The various dmat->lowaddr arrive in a strictly
	decreasing order
vs.
B2)	The various dmat->lowaddr arrive in increasing order

(B1) will produce a hw.busdma zone for each distinct value of
dmat->lowaddr .

(B2) will produce one hw.busdma zone with the smallest
dmat->lowaddr being used for all the bounce activity.
(The smallest could potentially be rather small.)

It turned out that the RPi4B basically had its smallest
dmat->lowaddr in the 2nd alloc_bounce_zone call so all
later alloc_bounce_zone calls used that zone. (The actual
size was relevant to me only because of the investigation
involved.) This wording is slightly simplified from the
actual context but should be suggestive enough.

(I changed ">=" to "==" for my investigative activity,
making the results be more like (B1), but independent of
dmat->lowaddr arrival order. The zone order ends up being
a permutation of (B1)'s order.)

Are there any consequence of (B1) vs. (B2) big enough to
make the existing implementation somewhat of a problem?
Since (B1) can happen anyway (so: is a valid result),
should the order dependency of alloc_bounce_zone's
behavior be removed to avoid (B2) type results?


===
Mark Millard
marklmi at yahoo.com