From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Piggin Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Date: Tue, 13 Sep 2016 12:16:45 +1000 Message-ID: <20160913121645.652e6512@roar.ozlabs.ibm.com> References: <147361509579.17004.5258725187329709824.stgit@dwillia2-desk3.amr.corp.intel.com> <20160912133536.1bdb57a9@roar.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Andrea Arcangeli , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Xiao Guangrong , Arnd Bergmann , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dave Hansen , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux MM , Andrew Morton , "Kirill A. Shutemov" List-Id: linux-api@vger.kernel.org On Mon, 12 Sep 2016 10:29:17 -0700 Dan Williams wrote: > On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin wrote: > > On Sun, 11 Sep 2016 10:31:35 -0700 > > Dan Williams wrote: > > > >> As evidenced by this bug report [1], userspace libraries are interested > >> in whether a mapping is DAX mapped, i.e. no intervening page cache. > >> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > >> explicit "is dax" indication as a new flag in the page vector populated > >> by mincore. > > > > Can you cc linux-arch when adding new syscalls (or other such things that > > need arch enablement). > > > > I wonder if the changelog for a new syscall should have a bit more grandeur. > > Without seeing patch 2, you might not know this was a new syscall just by > > reading the subject and changelog. > > Fair point, I'll beef up the documentation if this moves past an RFC. Okay. Also, it would be good to summarise some of the justification directly in the changelog rather than external link. Performance numbers, etc. > > mincore() defines other bits to be reserved, but I guess it probably breaks > > things if you suddenly started using them. > > The new bits are left as zero unless an application explicitly asks > for them, so an existing mincore() user shouldn't break. Oh yeah, I was just musing that we can't really use the old syscall despite it claims to have some reserved bits for future use. > > It's a bit sad to introduce a new syscall for this and immediately use up > > all bits that can be returned. Would it be a serious problem to return a > > larger mask per page? > > Certainly one of the new request flags can indicate that the vector is > made up of larger entries. Hmm. Changing prototype depending on flags. I thought I was having a nightmare about ioctls for a minute there :) In general, is this what we want for a new API? Should we be thinking about an extent API? Thanks, Nick From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f196.google.com ([209.85.192.196]:34740 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105AbcIMCQz (ORCPT ); Mon, 12 Sep 2016 22:16:55 -0400 Date: Tue, 13 Sep 2016 12:16:45 +1000 From: Nicholas Piggin Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Message-ID: <20160913121645.652e6512@roar.ozlabs.ibm.com> In-Reply-To: References: <147361509579.17004.5258725187329709824.stgit@dwillia2-desk3.amr.corp.intel.com> <20160912133536.1bdb57a9@roar.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dan Williams Cc: Linux MM , Andrea Arcangeli , Xiao Guangrong , Arnd Bergmann , "linux-nvdimm@lists.01.org" , linux-api@vger.kernel.org, Dave Hansen , "linux-kernel@vger.kernel.org" , Andrew Morton , "Kirill A. Shutemov" , linux-arch@vger.kernel.org Message-ID: <20160913021645.NoBHlrqzpISA9Pl0ENN_tFjkhcgO3n6zjgzn153r2lo@z> On Mon, 12 Sep 2016 10:29:17 -0700 Dan Williams wrote: > On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin wrote: > > On Sun, 11 Sep 2016 10:31:35 -0700 > > Dan Williams wrote: > > > >> As evidenced by this bug report [1], userspace libraries are interested > >> in whether a mapping is DAX mapped, i.e. no intervening page cache. > >> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > >> explicit "is dax" indication as a new flag in the page vector populated > >> by mincore. > > > > Can you cc linux-arch when adding new syscalls (or other such things that > > need arch enablement). > > > > I wonder if the changelog for a new syscall should have a bit more grandeur. > > Without seeing patch 2, you might not know this was a new syscall just by > > reading the subject and changelog. > > Fair point, I'll beef up the documentation if this moves past an RFC. Okay. Also, it would be good to summarise some of the justification directly in the changelog rather than external link. Performance numbers, etc. > > mincore() defines other bits to be reserved, but I guess it probably breaks > > things if you suddenly started using them. > > The new bits are left as zero unless an application explicitly asks > for them, so an existing mincore() user shouldn't break. Oh yeah, I was just musing that we can't really use the old syscall despite it claims to have some reserved bits for future use. > > It's a bit sad to introduce a new syscall for this and immediately use up > > all bits that can be returned. Would it be a serious problem to return a > > larger mask per page? > > Certainly one of the new request flags can indicate that the vector is > made up of larger entries. Hmm. Changing prototype depending on flags. I thought I was having a nightmare about ioctls for a minute there :) In general, is this what we want for a new API? Should we be thinking about an extent API? Thanks, Nick From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F3E081A1E21 for ; Mon, 12 Sep 2016 19:16:54 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id z84so548805pfi.2 for ; Mon, 12 Sep 2016 19:16:54 -0700 (PDT) Date: Tue, 13 Sep 2016 12:16:45 +1000 From: Nicholas Piggin Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Message-ID: <20160913121645.652e6512@roar.ozlabs.ibm.com> In-Reply-To: References: <147361509579.17004.5258725187329709824.stgit@dwillia2-desk3.amr.corp.intel.com> <20160912133536.1bdb57a9@roar.ozlabs.ibm.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Andrea Arcangeli , linux-arch@vger.kernel.org, Xiao Guangrong , Arnd Bergmann , "linux-nvdimm@lists.01.org" , linux-api@vger.kernel.org, Dave Hansen , "linux-kernel@vger.kernel.org" , Linux MM , Andrew Morton , "Kirill A. Shutemov" List-ID: On Mon, 12 Sep 2016 10:29:17 -0700 Dan Williams wrote: > On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin wrote: > > On Sun, 11 Sep 2016 10:31:35 -0700 > > Dan Williams wrote: > > > >> As evidenced by this bug report [1], userspace libraries are interested > >> in whether a mapping is DAX mapped, i.e. no intervening page cache. > >> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > >> explicit "is dax" indication as a new flag in the page vector populated > >> by mincore. > > > > Can you cc linux-arch when adding new syscalls (or other such things that > > need arch enablement). > > > > I wonder if the changelog for a new syscall should have a bit more grandeur. > > Without seeing patch 2, you might not know this was a new syscall just by > > reading the subject and changelog. > > Fair point, I'll beef up the documentation if this moves past an RFC. Okay. Also, it would be good to summarise some of the justification directly in the changelog rather than external link. Performance numbers, etc. > > mincore() defines other bits to be reserved, but I guess it probably breaks > > things if you suddenly started using them. > > The new bits are left as zero unless an application explicitly asks > for them, so an existing mincore() user shouldn't break. Oh yeah, I was just musing that we can't really use the old syscall despite it claims to have some reserved bits for future use. > > It's a bit sad to introduce a new syscall for this and immediately use up > > all bits that can be returned. Would it be a serious problem to return a > > larger mask per page? > > Certainly one of the new request flags can indicate that the vector is > made up of larger entries. Hmm. Changing prototype depending on flags. I thought I was having a nightmare about ioctls for a minute there :) In general, is this what we want for a new API? Should we be thinking about an extent API? Thanks, Nick _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f72.google.com (mail-pa0-f72.google.com [209.85.220.72]) by kanga.kvack.org (Postfix) with ESMTP id BDBAE6B025E for ; Mon, 12 Sep 2016 22:16:55 -0400 (EDT) Received: by mail-pa0-f72.google.com with SMTP id ex14so227860912pac.0 for ; Mon, 12 Sep 2016 19:16:55 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com. [2607:f8b0:400e:c00::242]) by mx.google.com with ESMTPS id xq1si24695708pab.11.2016.09.12.19.16.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 19:16:54 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id x24so8877747pfa.3 for ; Mon, 12 Sep 2016 19:16:54 -0700 (PDT) Date: Tue, 13 Sep 2016 12:16:45 +1000 From: Nicholas Piggin Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Message-ID: <20160913121645.652e6512@roar.ozlabs.ibm.com> In-Reply-To: References: <147361509579.17004.5258725187329709824.stgit@dwillia2-desk3.amr.corp.intel.com> <20160912133536.1bdb57a9@roar.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: Linux MM , Andrea Arcangeli , Xiao Guangrong , Arnd Bergmann , "linux-nvdimm@lists.01.org" , linux-api@vger.kernel.org, Dave Hansen , "linux-kernel@vger.kernel.org" , Andrew Morton , "Kirill A. Shutemov" , linux-arch@vger.kernel.org On Mon, 12 Sep 2016 10:29:17 -0700 Dan Williams wrote: > On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin wrote: > > On Sun, 11 Sep 2016 10:31:35 -0700 > > Dan Williams wrote: > > > >> As evidenced by this bug report [1], userspace libraries are interested > >> in whether a mapping is DAX mapped, i.e. no intervening page cache. > >> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > >> explicit "is dax" indication as a new flag in the page vector populated > >> by mincore. > > > > Can you cc linux-arch when adding new syscalls (or other such things that > > need arch enablement). > > > > I wonder if the changelog for a new syscall should have a bit more grandeur. > > Without seeing patch 2, you might not know this was a new syscall just by > > reading the subject and changelog. > > Fair point, I'll beef up the documentation if this moves past an RFC. Okay. Also, it would be good to summarise some of the justification directly in the changelog rather than external link. Performance numbers, etc. > > mincore() defines other bits to be reserved, but I guess it probably breaks > > things if you suddenly started using them. > > The new bits are left as zero unless an application explicitly asks > for them, so an existing mincore() user shouldn't break. Oh yeah, I was just musing that we can't really use the old syscall despite it claims to have some reserved bits for future use. > > It's a bit sad to introduce a new syscall for this and immediately use up > > all bits that can be returned. Would it be a serious problem to return a > > larger mask per page? > > Certainly one of the new request flags can indicate that the vector is > made up of larger entries. Hmm. Changing prototype depending on flags. I thought I was having a nightmare about ioctls for a minute there :) In general, is this what we want for a new API? Should we be thinking about an extent API? Thanks, Nick -- 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 S1753898AbcIMCQ5 (ORCPT ); Mon, 12 Sep 2016 22:16:57 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34740 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105AbcIMCQz (ORCPT ); Mon, 12 Sep 2016 22:16:55 -0400 Date: Tue, 13 Sep 2016 12:16:45 +1000 From: Nicholas Piggin To: Dan Williams Cc: Linux MM , Andrea Arcangeli , Xiao Guangrong , Arnd Bergmann , "linux-nvdimm@lists.01.org" , linux-api@vger.kernel.org, Dave Hansen , "linux-kernel@vger.kernel.org" , Andrew Morton , "Kirill A. Shutemov" , linux-arch@vger.kernel.org Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Message-ID: <20160913121645.652e6512@roar.ozlabs.ibm.com> In-Reply-To: References: <147361509579.17004.5258725187329709824.stgit@dwillia2-desk3.amr.corp.intel.com> <20160912133536.1bdb57a9@roar.ozlabs.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Sep 2016 10:29:17 -0700 Dan Williams wrote: > On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin wrote: > > On Sun, 11 Sep 2016 10:31:35 -0700 > > Dan Williams wrote: > > > >> As evidenced by this bug report [1], userspace libraries are interested > >> in whether a mapping is DAX mapped, i.e. no intervening page cache. > >> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > >> explicit "is dax" indication as a new flag in the page vector populated > >> by mincore. > > > > Can you cc linux-arch when adding new syscalls (or other such things that > > need arch enablement). > > > > I wonder if the changelog for a new syscall should have a bit more grandeur. > > Without seeing patch 2, you might not know this was a new syscall just by > > reading the subject and changelog. > > Fair point, I'll beef up the documentation if this moves past an RFC. Okay. Also, it would be good to summarise some of the justification directly in the changelog rather than external link. Performance numbers, etc. > > mincore() defines other bits to be reserved, but I guess it probably breaks > > things if you suddenly started using them. > > The new bits are left as zero unless an application explicitly asks > for them, so an existing mincore() user shouldn't break. Oh yeah, I was just musing that we can't really use the old syscall despite it claims to have some reserved bits for future use. > > It's a bit sad to introduce a new syscall for this and immediately use up > > all bits that can be returned. Would it be a serious problem to return a > > larger mask per page? > > Certainly one of the new request flags can indicate that the vector is > made up of larger entries. Hmm. Changing prototype depending on flags. I thought I was having a nightmare about ioctls for a minute there :) In general, is this what we want for a new API? Should we be thinking about an extent API? Thanks, Nick