Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753752AbdF2VrU (ORCPT ); Thu, 29 Jun 2017 17:47:20 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:40220 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753504AbdF2VrS (ORCPT ); Thu, 29 Jun 2017 17:47:18 -0400 Reply-To: prakash.sangappa@oracle.com Subject: Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery References: <9363561f-a9cd-7ab6-9c11-ab9a99dc89f1@oracle.com> <20170627070643.GA28078@dhcp22.suse.cz> <20170627153557.GB10091@rapoport-lnx> <51508e99-d2dd-894f-8d8a-678e3747c1ee@oracle.com> <20170628131806.GD10091@rapoport-lnx> <3a8e0042-4c49-3ec8-c59f-9036f8e54621@oracle.com> <20170629104605.GA24911@rapoport-lnx> To: Mike Rapoport Cc: Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli , Mike Kravetz , Dave Hansen , Christoph Hellwig , linux-api@vger.kernel.org From: "prakash.sangappa" Message-ID: <64c1f66e-95ca-7abb-6e22-44209ff7c73f@oracle.com> Date: Thu, 29 Jun 2017 14:49:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170629104605.GA24911@rapoport-lnx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1227 Lines: 39 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. >