From: Dan Williams <dan.j.williams@intel.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
linux-arch@vger.kernel.org,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-api@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range
Date: Mon, 12 Sep 2016 10:29:17 -0700 [thread overview]
Message-ID: <CAPcyv4hS7i1DApKPDB5PkfBNZVbk321FgP94kUDjmuyGXDidZg@mail.gmail.com> (raw)
In-Reply-To: <20160912133536.1bdb57a9@roar.ozlabs.ibm.com>
On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Sun, 11 Sep 2016 10:31:35 -0700
> Dan Williams <dan.j.williams@intel.com> 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.
> 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.
> 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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Linux MM <linux-mm@kvack.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
linux-api@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range
Date: Mon, 12 Sep 2016 10:29:17 -0700 [thread overview]
Message-ID: <CAPcyv4hS7i1DApKPDB5PkfBNZVbk321FgP94kUDjmuyGXDidZg@mail.gmail.com> (raw)
In-Reply-To: <20160912133536.1bdb57a9@roar.ozlabs.ibm.com>
On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Sun, 11 Sep 2016 10:31:35 -0700
> Dan Williams <dan.j.williams@intel.com> 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.
> 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.
> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Linux MM <linux-mm@kvack.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-api@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range
Date: Mon, 12 Sep 2016 10:29:17 -0700 [thread overview]
Message-ID: <CAPcyv4hS7i1DApKPDB5PkfBNZVbk321FgP94kUDjmuyGXDidZg@mail.gmail.com> (raw)
In-Reply-To: <20160912133536.1bdb57a9@roar.ozlabs.ibm.com>
On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Sun, 11 Sep 2016 10:31:35 -0700
> Dan Williams <dan.j.williams@intel.com> 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.
> 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.
> 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.
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Linux MM <linux-mm@kvack.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-api@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range
Date: Mon, 12 Sep 2016 10:29:17 -0700 [thread overview]
Message-ID: <CAPcyv4hS7i1DApKPDB5PkfBNZVbk321FgP94kUDjmuyGXDidZg@mail.gmail.com> (raw)
Message-ID: <20160912172917.zcV41ENqkgFwfA8dCyqc5q7jvja0fgL-r7fyV5e723I@z> (raw)
In-Reply-To: <20160912133536.1bdb57a9@roar.ozlabs.ibm.com>
On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Sun, 11 Sep 2016 10:31:35 -0700
> Dan Williams <dan.j.williams@intel.com> 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.
> 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.
> 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.
next prev parent reply other threads:[~2016-09-12 17:29 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-11 17:31 [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Dan Williams
2016-09-11 17:31 ` Dan Williams
2016-09-11 17:31 ` Dan Williams
2016-09-11 17:31 ` [RFC PATCH 2/2] x86: wire up mincore2() Dan Williams
2016-09-11 17:31 ` Dan Williams
2016-09-11 17:31 ` Dan Williams
2016-09-11 17:31 ` Dan Williams
2016-09-13 18:44 ` Ingo Molnar
2016-09-13 18:44 ` Ingo Molnar
2016-09-13 18:44 ` Ingo Molnar
2016-09-13 18:44 ` Ingo Molnar
2016-09-12 3:35 ` [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range Nicholas Piggin
2016-09-12 3:35 ` Nicholas Piggin
2016-09-12 3:35 ` Nicholas Piggin
2016-09-12 3:35 ` Nicholas Piggin
2016-09-12 3:35 ` Nicholas Piggin
2016-09-12 17:29 ` Dan Williams [this message]
2016-09-12 17:29 ` Dan Williams
2016-09-12 17:29 ` Dan Williams
2016-09-12 17:29 ` Dan Williams
2016-09-13 2:16 ` Nicholas Piggin
2016-09-13 2:16 ` Nicholas Piggin
2016-09-13 2:16 ` Nicholas Piggin
2016-09-13 2:16 ` Nicholas Piggin
2016-09-13 2:16 ` Nicholas Piggin
2016-09-13 3:49 ` Dan Williams
2016-09-13 3:49 ` Dan Williams
2016-09-13 3:49 ` Dan Williams
2016-09-13 3:49 ` Dan Williams
2016-09-12 6:29 ` Oliver O'Halloran
2016-09-12 6:29 ` Oliver O'Halloran
2016-09-12 6:29 ` Oliver O'Halloran
2016-09-12 17:25 ` Dan Williams
2016-09-12 17:25 ` Dan Williams
2016-09-12 17:25 ` Dan Williams
2016-09-12 17:25 ` Dan Williams
2016-09-12 10:09 ` Kirill A. Shutemov
2016-09-12 10:09 ` Kirill A. Shutemov
2016-09-12 10:09 ` Kirill A. Shutemov
2016-09-12 10:09 ` Kirill A. Shutemov
2016-09-12 17:15 ` Dan Williams
2016-09-12 17:15 ` Dan Williams
2016-09-12 17:15 ` Dan Williams
[not found] ` <147361509579.17004.5258725187329709824.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-09-13 6:44 ` Christoph Hellwig
2016-09-13 6:44 ` Christoph Hellwig
2016-09-13 6:44 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPcyv4hS7i1DApKPDB5PkfBNZVbk321FgP94kUDjmuyGXDidZg@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dave.hansen@linux.intel.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.