On Tue, Jan 17, 2023 at 10:54 PM John Stultz <jstultz@xxxxxxxxxx> wrote: > > On Tue, Jan 17, 2023 at 12:31 AM Jaewon Kim <jaewon31.kim@xxxxxxxxxxx> wrote: > > > Using order 4 pages would be helpful for many IOMMUs, but it could spend > > > quite much time in page allocation perspective. > > > > > > The order 4 allocation with __GFP_RECLAIM may spend much time in > > > reclaim and compation logic. __GFP_NORETRY also may affect. These cause > > > unpredictable delay. > > > > > > To get reasonable allocation speed from dma-buf system heap, use > > > HIGH_ORDER_GFP for order 4 to avoid reclaim. > > Thanks for sharing this! > The case where the allocation gets stuck behind reclaim under pressure > does sound undesirable, but I'd be a bit hesitant to tweak numbers > that have been used for a long while (going back to ion) without a bit > more data. > > It might be good to also better understand the tradeoff of potential > on-going impact to performance from using low order pages when the > buffer is used. Do you have any details like or tests that you could > share to help ensure this won't impact other users? > > TJ: Do you have any additional thoughts on this? > I don't have any data on how often we hit reclaim for mid order allocations. That would be interesting to know. However the 70th percentile of system-wide buffer sizes while running the camera on my phone is still only 1 page, so it looks like this change would affect a subset of use-cases. Wouldn't this change make it less likely to get an order 4 allocation (under memory pressure)? The commit message makes me think the goal of the change is to get more of them. Actually with the low order being 0, I don't think __GFP_COMP makes sense in LOW_ORDER_GFP. But I guess that flag isn't harmful there. > thanks > -john
