On Tue, Sep 03, 2024 at 10:50:09AM +1200, Barry Song wrote: > From: Barry Song <v-songbaohua@xxxxxxxx> > > The mmap_write_lock() can block all access to the VMAs, for example page > faults. Performing memory allocation while holding this lock may trigger > direct reclamation, leading to others being queued in the rwsem for an > extended period. > We've observed that the allocation can sometimes take more than 300ms, > significantly blocking other threads. The user interface sometimes > becomes less responsive as a result. To prevent this, let's move the > allocation outside of the write lock. I suspect concurrent allocators make things better wrt response, cutting alloc latency down to 10ms for instance in your scenario. Feel free to show figures given Tangquan's 48-hour profiling. > A potential side effect could be an extra alloc_page() for the second > thread executing binder_install_single_page() while the first thread > has done it earlier. However, according to Tangquan's 48-hour profiling > using monkey, the likelihood of this occurring is minimal, with a ratio > of only 1 in 2400. Compared to the significantly costly rwsem, this is > negligible. > On the other hand, holding a write lock without making any VMA > modifications appears questionable and likely incorrect. While this > patch focuses on reducing the lock duration, future updates may aim > to eliminate the write lock entirely. If spin, better not before taking a look at vm_insert_page().
