Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Nicholas Piggin]

On Sun, 11 Sep 2016 10:31:35 -0700
Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 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.

mincore() defines other bits to be reserved, but I guess it probably breaks
things if you suddenly started using them.

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?

Thanks,
Nick

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Nicholas Piggin]

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.

mincore() defines other bits to be reserved, but I guess it probably breaks
things if you suddenly started using them.

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?

Thanks,
Nick

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Dan Williams]

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>

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Dan Williams]

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.

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Nicholas Piggin]

On Mon, 12 Sep 2016 10:29:17 -0700
Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> On Sun, Sep 11, 2016 at 8:35 PM, Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sun, 11 Sep 2016 10:31:35 -0700
> > Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 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

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Nicholas Piggin]

On Mon, 12 Sep 2016 10:29:17 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> 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.

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

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Dan Williams]

On Mon, Sep 12, 2016 at 7:16 PM, Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, 12 Sep 2016 10:29:17 -0700
[..]
>> 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 :)

Heh :)

> In general, is this what we want for a new API? Should we be thinking
> about an extent API?

This probably fits better with the use cases I know that want to
consume this information, something like fiemap (mextmap, maybe?) for
memory.

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Dan Williams]

On Mon, Sep 12, 2016 at 7:16 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Mon, 12 Sep 2016 10:29:17 -0700
[..]
>> 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 :)

Heh :)

> In general, is this what we want for a new API? Should we be thinking
> about an extent API?

This probably fits better with the use cases I know that want to
consume this information, something like fiemap (mextmap, maybe?) for
memory.