On 6/28/17 6:18 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:01:20AM -0700, Prakash Sangappa wrote:
On 6/27/17 8:35 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
Any access to mapped address over holes in the file, which can occur due
to bugs in the application, is considered invalid and expect the process
to simply receive a SIGBUS. However, currently when a hole in the file is
accessed via the mapped address, kernel/mm attempts to automatically
allocate a page at page fault time, resulting in implicitly filling the
hole in the file. This may not be the desired behavior for applications
like the database that want to explicitly manage page allocations of
hugetlbfs files.
So you register UFFD_FEATURE_SIGBUS on each region tha you are unmapping
and than just let those offenders die?
If I understand correctly, the database will create the mapping, then it'll
open userfaultfd and register those mappings with the userfault.
Afterwards, when the application accesses a hole userfault will cause
SIGBUS and the application will process it in whatever way it likes, e.g.
just die.
Yes.
What I don't understand is why won't you use userfault monitor process that
will take care of the page fault events?
It shouldn't be much overhead running it and it can keep track on all the
userfault file descriptors for you and it will allow more versatile error
handling that SIGBUS.
Co-ordination with the external monitor process by all the database
processes
to send their userfaultfd is still an overhead.
You are planning to register in userfaultfd only the holes you punch to
deallocate pages, am I right?
No, the entire mmap'ed region. The DB processes would mmap(MAP_NORESERVE)
hugetlbfs files, register this mapped address with userfaultfd ones
right after
the mmap() call.
And the co-ordination of the userfault file descriptor with the monitor
would have been added after calls to fallocate() and userfaultfd_register()?
Well, the database application does not need to deal with a monitor.
I've just been thinking that maybe it would be possible to use
UFFD_EVENT_REMOVE for this case. We anyway need to implement the generation
of UFFD_EVENT_REMOVE for the case of hole punching in hugetlbfs for
non-cooperative userfaultfd. It could be that it will solve your issue as
well.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
