Yunsheng Lin <linyunsheng@xxxxxxxxxx> writes: > On 2024/10/26 15:33, Yunsheng Lin wrote: > > ... > >>>> >>>> AFAIU Jakub's comment on his RFC patch for waiting, he was suggesting >>>> exactly this: Add the wait, and see if the cases where it can stall turn >>>> out to be problems in practice. >>> >>> +1 >>> >>> I like Jakub's approach. >> >> As mentioned in Toke's comment, I am still not convinced that there is some >> easy way of waiting here, doing the kick in the kernel space is hard enough, >> I am not even sure if kick need to be done or how it can be done in the user >> space if some page_pool owned page is held from user space for the cases of zero >> rx copy, io_uring and devmem tcp? killing the userspace app? >> >> If you and Toke still think the waiting is the way out for the problem here, maybe >> we should wait for jakub's opinion and let him decide if he want to proceed with >> his waiting patch. > > 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. 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 :) -Toke
