On 2024/11/12 2:51, Toke Høiland-Jørgensen wrote: ... >> >> Is there any other suggestion/concern about how to fix the problem here? >> >> From the previous discussion, it seems the main concern about tracking the >> inflight pages is about how many inflight pages it is needed. > > Yeah, my hardest objection was against putting a hard limit on the > number of outstanding pages. > >> If there is no other suggestion/concern , it seems the above concern might be >> addressed by using pre-allocated memory to satisfy the mostly used case, and >> use the dynamically allocated memory if/when necessary. > > For this, my biggest concern would be performance. > > In general, doing extra work in rarely used code paths (such as device > teardown) is much preferred to adding extra tracking in the fast path. > Which would be an argument for Alexander's suggestion of just scanning > the entire system page table to find pages to unmap. Don't know enough > about mm system internals to have an opinion on whether this is > feasible, though. Yes, there seems to be many MM system internals, like the CONFIG_SPARSEMEM* config, memory offline/online and other MM specific optimization that it is hard to tell it is feasible. It would be good if MM experts can clarify on this. > > In any case, we'll need some numbers to really judge the overhead in > practice. So benchmarking would be the logical next step in any case :) Using POC code show that using the dynamic memory allocation does not seems to be adding much overhead than the pre-allocated memory allocation in this patch, the overhead is about 10~20ns, which seems to be similar to the overhead of added overhead in the patch. > > -Toke > >
