From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery Date: Tue, 4 Jul 2017 18:40:34 +0200 Message-ID: <20170704164034.GH5738@redhat.com> References: <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> <20170629080910.GC31603@dhcp22.suse.cz> <936bde7b-1913-5589-22f4-9bbfdb6a8dd5@oracle.com> <20170630094718.GE22917@dhcp22.suse.cz> <20170630130813.GA5738@redhat.com> <5956F2EC.1000805@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <5956F2EC.1000805-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: prakash sangappa Cc: Michal Hocko , Mike Rapoport , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Mike Kravetz , Dave Hansen , Christoph Hellwig , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, John Stultz List-Id: linux-api@vger.kernel.org On Fri, Jun 30, 2017 at 05:55:08PM -0700, prakash sangappa wrote: > Interesting that UFFDIO_COPY is faster then fallocate(). In the DB use case > the page does not need to be allocated at the time a process trips on > the hugetlbfs > file hole and receives SIGBUS. fallocate() is called on the hugetlbfs file, > when more memory needs to be allocated by a separate process. The major difference is that with UFFDIO_COPY the hugepage will be immediately mapped into the virtual address without requiring any further minor fault. So it's ideal if you could arrange to call UFFDIO_COPY from the same process that is going to touch and use the hugetlbfs data immediately after. You would eliminate a minor fault that way. UFFDIO_COPY at least for anon was measured to perform better than a regular page fault too. > Regarding hugetlbfs mount option, one consideration is to allow mounts of > hugetlbfs inside user namespaces's mount namespace. Which would allow > non privileged processes to mount hugetlbfs for use inside a user > namespace. > This may be needed even for the 'min_size' mount option using which an > application could reserve huge pages and mount a filesystem for its use, > with out the need to have privileges given the system has enough hugepages > configured. It seems if non privileged processes are allowed to mount > hugetlbfs > filesystem, then min_size should be subject to some resource limits. > > Mounting inside user namespace will be a different patch proposal later. There's no particular reason to make UFFDIO_FEATURE_SIGBUS a privileged op unless we want to eliminate the branch with the static key, so it's certainly simpler than dealing with hugetlbfs min_size reserves. I'm positive about the UFFDIO_FEATURE_SIGBUS tradeoffs, but others feel free to comment. If you could make second patch to extend the selftest to exercise and validates UFFDIO_FEATURE_SIGBUS in anon/shmem/hugetlbfs it'd be great. Thanks, Andrea From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by kanga.kvack.org (Postfix) with ESMTP id 7245C6B0279 for ; Tue, 4 Jul 2017 12:40:38 -0400 (EDT) Received: by mail-qt0-f200.google.com with SMTP id o8so110047939qtc.1 for ; Tue, 04 Jul 2017 09:40:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id b12si18897536qkb.344.2017.07.04.09.40.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 09:40:37 -0700 (PDT) Date: Tue, 4 Jul 2017 18:40:34 +0200 From: Andrea Arcangeli Subject: Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery Message-ID: <20170704164034.GH5738@redhat.com> References: <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> <20170629080910.GC31603@dhcp22.suse.cz> <936bde7b-1913-5589-22f4-9bbfdb6a8dd5@oracle.com> <20170630094718.GE22917@dhcp22.suse.cz> <20170630130813.GA5738@redhat.com> <5956F2EC.1000805@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5956F2EC.1000805@oracle.com> Sender: owner-linux-mm@kvack.org List-ID: To: prakash sangappa Cc: Michal Hocko , Mike Rapoport , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Kravetz , Dave Hansen , Christoph Hellwig , linux-api@vger.kernel.org, John Stultz On Fri, Jun 30, 2017 at 05:55:08PM -0700, prakash sangappa wrote: > Interesting that UFFDIO_COPY is faster then fallocate(). In the DB use case > the page does not need to be allocated at the time a process trips on > the hugetlbfs > file hole and receives SIGBUS. fallocate() is called on the hugetlbfs file, > when more memory needs to be allocated by a separate process. The major difference is that with UFFDIO_COPY the hugepage will be immediately mapped into the virtual address without requiring any further minor fault. So it's ideal if you could arrange to call UFFDIO_COPY from the same process that is going to touch and use the hugetlbfs data immediately after. You would eliminate a minor fault that way. UFFDIO_COPY at least for anon was measured to perform better than a regular page fault too. > Regarding hugetlbfs mount option, one consideration is to allow mounts of > hugetlbfs inside user namespaces's mount namespace. Which would allow > non privileged processes to mount hugetlbfs for use inside a user > namespace. > This may be needed even for the 'min_size' mount option using which an > application could reserve huge pages and mount a filesystem for its use, > with out the need to have privileges given the system has enough hugepages > configured. It seems if non privileged processes are allowed to mount > hugetlbfs > filesystem, then min_size should be subject to some resource limits. > > Mounting inside user namespace will be a different patch proposal later. There's no particular reason to make UFFDIO_FEATURE_SIGBUS a privileged op unless we want to eliminate the branch with the static key, so it's certainly simpler than dealing with hugetlbfs min_size reserves. I'm positive about the UFFDIO_FEATURE_SIGBUS tradeoffs, but others feel free to comment. If you could make second patch to extend the selftest to exercise and validates UFFDIO_FEATURE_SIGBUS in anon/shmem/hugetlbfs it'd be great. Thanks, Andrea -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752540AbdGDQki (ORCPT ); Tue, 4 Jul 2017 12:40:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59922 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752244AbdGDQkh (ORCPT ); Tue, 4 Jul 2017 12:40:37 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 568A2C0587D1 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aarcange@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 568A2C0587D1 Date: Tue, 4 Jul 2017 18:40:34 +0200 From: Andrea Arcangeli To: prakash sangappa Cc: Michal Hocko , Mike Rapoport , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Kravetz , Dave Hansen , Christoph Hellwig , linux-api@vger.kernel.org, John Stultz Subject: Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery Message-ID: <20170704164034.GH5738@redhat.com> References: <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> <20170629080910.GC31603@dhcp22.suse.cz> <936bde7b-1913-5589-22f4-9bbfdb6a8dd5@oracle.com> <20170630094718.GE22917@dhcp22.suse.cz> <20170630130813.GA5738@redhat.com> <5956F2EC.1000805@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5956F2EC.1000805@oracle.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 04 Jul 2017 16:40:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 30, 2017 at 05:55:08PM -0700, prakash sangappa wrote: > Interesting that UFFDIO_COPY is faster then fallocate(). In the DB use case > the page does not need to be allocated at the time a process trips on > the hugetlbfs > file hole and receives SIGBUS. fallocate() is called on the hugetlbfs file, > when more memory needs to be allocated by a separate process. The major difference is that with UFFDIO_COPY the hugepage will be immediately mapped into the virtual address without requiring any further minor fault. So it's ideal if you could arrange to call UFFDIO_COPY from the same process that is going to touch and use the hugetlbfs data immediately after. You would eliminate a minor fault that way. UFFDIO_COPY at least for anon was measured to perform better than a regular page fault too. > Regarding hugetlbfs mount option, one consideration is to allow mounts of > hugetlbfs inside user namespaces's mount namespace. Which would allow > non privileged processes to mount hugetlbfs for use inside a user > namespace. > This may be needed even for the 'min_size' mount option using which an > application could reserve huge pages and mount a filesystem for its use, > with out the need to have privileges given the system has enough hugepages > configured. It seems if non privileged processes are allowed to mount > hugetlbfs > filesystem, then min_size should be subject to some resource limits. > > Mounting inside user namespace will be a different patch proposal later. There's no particular reason to make UFFDIO_FEATURE_SIGBUS a privileged op unless we want to eliminate the branch with the static key, so it's certainly simpler than dealing with hugetlbfs min_size reserves. I'm positive about the UFFDIO_FEATURE_SIGBUS tradeoffs, but others feel free to comment. If you could make second patch to extend the selftest to exercise and validates UFFDIO_FEATURE_SIGBUS in anon/shmem/hugetlbfs it'd be great. Thanks, Andrea