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

0 files changed, 0 insertions, 0 deletions