On 2/25/22 15:21, Theodore Ts'o wrote:
...
For process_vm_writev() this is a case where user pages are pinned and
then released in short order, so I suspect that race with the page
cleaner would also be very hard to hit. But we could completely
remove the potential for the race, and also make things kinder for
Completely removing the race would be wonderful. Because large
supercomputer installations are good at hitting "rare" cases.
f2fs and btrfs's compressed file write support, by making things work
much like the write(2) system call. Imagine if we had a
"pin_user_pages_local()" which calls write_begin(), and a
"unpin_user_pages_local()" which calls write_end(), and the
Right, that would supply the missing connection to the filesystems.
In fact, maybe these names about right:
pin_user_file_pages()
unpin_user_file_pages()
...and then put them in a filesystem header file, because these are now
tightly coupled to filesystems, what with the need to call
.write_begin() and .write_end().
OK...
presumption with the "[un]pin_user_pages_local" API is that you don't
hold the pinned pages for very long --- say, not across a system call
boundary, and then it would work the same way the write(2) system call
works does except that in the case of process_vm_writev(2) the pages
are identified by another process's address space where they happen to
be mapped.
This obviously doesn't work when pinning pages for remote DMA, because
in that case the time between pin_user_pages_remote() and
unpin_user_pages_remote() could be a long, long time, so that means we
can't use using write_begin/write_end; we'd need to call page_mkwrite()
when the pages are first pinned and then somehow prevent the page
cleaner from touching a dirty page which is pinned for use by the
remote DMA.
Does that make sense?
- Ted
Yes, I really like this suggestion. It would neatly solve most short
term pinning cases, without interfering with any future solutions for
the long term pinning cases. Very nice.
thanks,
--
John Hubbard
NVIDIA
