Messages in this thread | | | Subject | Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery | From | "prakash.sangappa" <> | Date | Thu, 29 Jun 2017 14:49:01 -0700 |
| |
On 06/29/2017 03:46 AM, Mike Rapoport wrote: > On Wed, Jun 28, 2017 at 11:23:32AM -0700, Prakash Sangappa wrote: [...] >> >> Will this result in a signal delivery? >> >> In the use case described, the database application does not need any event >> for hole punching. Basically, just a signal for any invalid access to >> mapped >> area over holes in the file. > > Well, what I had in mind was using a single-process uffd monitor that will > track all the userfault file descriptors. With UFFD_EVENT_REMOVE this > process will know what areas are invalid and it will be able to process the > invalid access in any way it likes, e.g. send SIGBUS to the database > application.
Use of a monitor process is also an overhead for the database.
> > If you mmap() and userfaultfd_register() only at the initialization time, > it might be also possible to avoid sending userfault file descriptors to > the monitor process with UFFD_FEATURE_EVENT_FORK.
The new processes are always exec'd in the database case and these processes could be mapping different files. So, not sure if UFFD_FEATURE_EVENT_FORK will be useful. Also, it may not be one process spawning the other new processes.
> > -- > Sincerely yours, > Mike. >
| |