A possibly unintended consequence of the kernel's alloc_bounce_zone implementation?
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 07 Dec 2022 21:42:24 UTC
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