Handle EAGAIN (due to map_lock contention) from uffd ops
This CL does the following:
1) Skip setting 'mapping' state for the pages before they are being
mapped. This helps with eliminating priority inversion. Kernel
returns EEXIST when any thread attempts to map a page which is
already mapped.
2) When kernel supports MMAP_TRYLOCK mode for COPY/ZEROPAGE ioctls, use
the mode to avoid clogging mmap_lock's wait-list. Mutator's delay is
decided based on their native-priority.
3) GC-thread doesn't waste time in mmap_lock's wait-list as long as
there are pages remaining to be compacted. But after that, it maps
all the pages even if that means waiting for lock. However, due to
`mmap_lock_is_contended` check in the kernel, the ioctl immediately
returns thereby not holding up writers and re-attempts the ioctl for
remaining pages.
Bug: 320478828
Test: boot cuttlefish instance with 5.15 kernel
Change-Id: I9e7d1df27f99b7179bb475a5b0bb587093caa549
2 files changed
