On Sat, Jan 09, 2021 at 09:51:14PM -0500, Andrea Arcangeli wrote: > Are we spending 32bit in mm_struct atomic_t just to call atomic_set(1) > on it? Why isn't it a MMF_HAS_PINNED that already can be set > atomically under mmap_read_lock too? There's bit left free there, we > didn't run out yet to justify wasting another 31 bits. I hope I'm > overlooking something. It needs to be atomic because it is set under gup fast, no mmap lock. Peter and myself did not find another place to put this that was already atomic > The existence of FOLL_LONGTERM is good and makes a difference at times > for writeback if it's on a MAP_SHARED, or it makes difference during > GUP to do a page_migrate before taking the pin, but for the whole rest > of the VM it's irrelevant if it's long or short term, so I'm also > concerned from what Jason mentioned about long term pins being treated > differently within the VM. Why? They are different. write protect doesn't stop modification of the data. How is that not a relavent and real difference? Jason
