Messages in this thread | | | From | "T.J. Mercier" <> | Date | Wed, 18 Jan 2023 11:55:07 -0800 | Subject | Re: [PATCH] dma-buf: system_heap: avoid reclaim for order 4 |
| |
On Tue, Jan 17, 2023 at 10:54 PM John Stultz <jstultz@google.com> wrote: > > On Tue, Jan 17, 2023 at 12:31 AM Jaewon Kim <jaewon31.kim@samsung.com> 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
| |