On Fri, 31 Jan 2025, Lorenzo Stoakes wrote:
On Thu, Jan 16, 2025 at 05:30:58PM -0800, SeongJae Park wrote:
Optimize redundant mmap lock operations from process_madvise() by
directly doing the mmap locking first, and then the remaining works for
all ranges in the loop.
Signed-off-by: SeongJae Park <sj@xxxxxxxxxx>
I wonder if this might increase lock contention because now all of the
vector operations will hold the relevant mm lock without releasing after
each operation?
That was exactly my concern. While afaict the numbers presented in v1
are quite nice, this is ultimately a micro-benchmark, where no other
unrelated threads are impacted by these new hold times.
Probably it's ok given limited size of iov, but maybe in future we'd want
to set a limit on the ranges before we drop/reacquire lock?
imo, this should best be done in the same patch/series. Maybe extend
the benchmark to use IOV_MAX and find a sweet spot?
Thanks,
Davidlohr
