Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1203575 > unrolled thread

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-09 07:30 +0200
    Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-12 14:00 +0200
      Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-19 23:40 +0200
        Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-20 10:00 +0200
          Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-20 19:10 +0200
            Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-21 09:30 +0200
              Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-21 20:40 +0200
                Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Konstantin Khlebnikov <koct9i@gmail.com> - 2015-08-24 12:20 +0200
                  Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Vlastimil Babka <vbabka@suse.cz> - 2015-08-24 15:40 +0200
                    Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Konstantin Khlebnikov <koct9i@gmail.com> - 2015-08-24 16:00 +0200
                      Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Vlastimil Babka <vbabka@suse.cz> - 2015-08-24 16:30 +0200
                        Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-24 17:10 +0200
                          Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Konstantin Khlebnikov <koct9i@gmail.com> - 2015-08-24 17:50 +0200
                            Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-24 18:00 +0200
                              Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Konstantin Khlebnikov <koct9i@gmail.com> - 2015-08-24 18:30 +0200
                                Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-24 19:10 +0200
                                  Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Konstantin Khlebnikov <koct9i@gmail.com> - 2015-08-24 21:00 +0200
                                    Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-24 22:30 +0200
                Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-25 15:50 +0200
                  Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Vlastimil Babka <vbabka@suse.cz> - 2015-08-25 16:00 +0200
                    Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-25 16:30 +0200
                  Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Konstantin Khlebnikov <koct9i@gmail.com> - 2015-08-25 16:00 +0200
                  Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-25 16:30 +0200
                    Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-25 21:00 +0200
                      Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-08-25 21:10 +0200
                        Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Michal Hocko <mhocko@kernel.org> - 2015-08-26 09:30 +0200
                          Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Vlastimil Babka <vbabka@suse.cz> - 2015-08-26 17:40 +0200
        Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Vlastimil Babka <vbabka@suse.cz> - 2015-08-20 10:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1213077

On Tue 25-08-15 15:55:46, Vlastimil Babka wrote:
> On 08/25/2015 03:41 PM, Michal Hocko wrote:
[...]
> >So what we have as a result is that partially populated ranges are
> >preserved and fully populated ones work in the best effort mode the same
> >way as they are now.
> >
> >Does that sound at least remotely reasonably?
> 
> I'll basically repeat what I said earlier:
> 
> - mremap scanning existing pte's to figure out the population would slow it
> down for no good reason

So do we really need to populate the enlarged range? All the man page is
saying is that the lock is maintained. Which will be still the case. It
is true that the failure is unlikely (unless you are running in the
memcg) but you cannot rely on the full mlock semantic so what would be a
problem?

> - it would be unreliable anyway:
>   - example: was the area completely populated because MLOCK_ONFAULT was not
> used or because the  process faulted it already

OK, I see this as being a problem. Especially if the buffer is increase
2*original_len

>   - example: was the area not completely populated because MLOCK_ONFAULT was
> used, or because mmap(MAP_LOCKED) failed to populate it fully?

What would be the difference? Both are ONFAULT now.

> I think the first point is a pointless regression for workloads that use
> just plain mlock() and don't want the onfault semantics. Unless there's some
> shortcut? Does vma have a counter of how much is populated? (I don't think
> so?)

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213049

On Tue, Aug 25, 2015 at 4:41 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Fri 21-08-15 14:31:32, Eric B Munson wrote:
> [...]
>> I am in the middle of implementing lock on fault this way, but I cannot
>> see how we will hanlde mremap of a lock on fault region.  Say we have
>> the following:
>>
>>     addr = mmap(len, MAP_ANONYMOUS, ...);
>>     mlock(addr, len, MLOCK_ONFAULT);
>>     ...
>>     mremap(addr, len, 2 * len, ...)
>>
>> There is no way for mremap to know that the area being remapped was lock
>> on fault so it will be locked and prefaulted by remap.  How can we avoid
>> this without tracking per vma if it was locked with lock or lock on
>> fault?
>
> Yes mremap is a problem and it is very much similar to mmap(MAP_LOCKED).
> It doesn't guarantee the full mlock semantic because it leaves partially
> populated ranges behind without reporting any error.
>
> Considering the current behavior I do not thing it would be terrible
> thing to do what Konstantin was suggesting and populate only the full
> ranges in a best effort mode (it is done so anyway) and document the
> behavior properly.
> "
>        If the memory segment specified by old_address and old_size is
>        locked (using mlock(2) or similar), then this lock is maintained
>        when the segment is resized and/or relocated. As a consequence,
>        the amount of memory locked by the process may change.
>
>        If the range is already fully populated and the range is
>        enlarged the new range is attempted to be fully populated
>        as well to preserve the full mlock semantic but there is no
>        guarantee this will succeed. Partially populated (e.g. created by
>        mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
>        so they are not populated on resize.
> "
>
> So what we have as a result is that partially populated ranges are
> preserved and fully populated ones work in the best effort mode the same
> way as they are now.
>
> Does that sound at least remotely reasonably?

The problem is that mremap have to scan ptes to detect that and old behaviour
becomes very fragile: one fail and mremap will never populate that vma again.
For now I think new flag "MREMAP_NOPOPULATE" is a better option.

>
>
> --
> Michal Hocko
> SUSE Labs
>
> --
> 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>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213078

[Multipart message — attachments visible in raw view] — view raw

On Tue, 25 Aug 2015, Michal Hocko wrote:

> On Fri 21-08-15 14:31:32, Eric B Munson wrote:
> [...]
> > I am in the middle of implementing lock on fault this way, but I cannot
> > see how we will hanlde mremap of a lock on fault region.  Say we have
> > the following:
> > 
> >     addr = mmap(len, MAP_ANONYMOUS, ...);
> >     mlock(addr, len, MLOCK_ONFAULT);
> >     ...
> >     mremap(addr, len, 2 * len, ...)
> > 
> > There is no way for mremap to know that the area being remapped was lock
> > on fault so it will be locked and prefaulted by remap.  How can we avoid
> > this without tracking per vma if it was locked with lock or lock on
> > fault?
> 
> Yes mremap is a problem and it is very much similar to mmap(MAP_LOCKED).
> It doesn't guarantee the full mlock semantic because it leaves partially
> populated ranges behind without reporting any error.

This was not my concern.  Instead, I was wondering how to keep lock on
fault sematics with mremap if we do not have a VMA flag.  As a user, it
would surprise me if a region I mlocked with lock on fault and then
remapped to a larger size was fully populated and locked by the mremap
call.

> 
> Considering the current behavior I do not thing it would be terrible
> thing to do what Konstantin was suggesting and populate only the full
> ranges in a best effort mode (it is done so anyway) and document the
> behavior properly.
> "
>        If the memory segment specified by old_address and old_size is
>        locked (using mlock(2) or similar), then this lock is maintained
>        when the segment is resized and/or relocated. As a consequence,
>        the amount of memory locked by the process may change.
> 
>        If the range is already fully populated and the range is
>        enlarged the new range is attempted to be fully populated
>        as well to preserve the full mlock semantic but there is no
>        guarantee this will succeed. Partially populated (e.g. created by
>        mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
>        so they are not populated on resize.
> "

You are proposing that mremap would scan the PTEs as Vlastimil has
suggested?

> 
> So what we have as a result is that partially populated ranges are
> preserved and fully populated ones work in the best effort mode the same
> way as they are now.
> 
> Does that sound at least remotely reasonably?
> 
> 
> -- 
> Michal Hocko
> SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1213245

On Tue 25-08-15 10:29:02, Eric B Munson wrote:
> On Tue, 25 Aug 2015, Michal Hocko wrote:
[...]
> > Considering the current behavior I do not thing it would be terrible
> > thing to do what Konstantin was suggesting and populate only the full
> > ranges in a best effort mode (it is done so anyway) and document the
> > behavior properly.
> > "
> >        If the memory segment specified by old_address and old_size is
> >        locked (using mlock(2) or similar), then this lock is maintained
> >        when the segment is resized and/or relocated. As a consequence,
> >        the amount of memory locked by the process may change.
> > 
> >        If the range is already fully populated and the range is
> >        enlarged the new range is attempted to be fully populated
> >        as well to preserve the full mlock semantic but there is no
> >        guarantee this will succeed. Partially populated (e.g. created by
> >        mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
> >        so they are not populated on resize.
> > "
> 
> You are proposing that mremap would scan the PTEs as Vlastimil has
> suggested?

As Vlastimil pointed out this would be unnecessarily too costly. But I
am wondering whether we should populate at all during mremap considering
the full mlock semantic is not guaranteed anyway. Man page mentions only
that the lock is maintained which will be true without population as
well.

If somebody really depends on the current (and broken) implementation we
can offer MREMAP_POPULATE which would do a best effort population. This
would be independent on the locked state and would be usable for other
mappings as well (the usecase would be to save page fault overhead by
batching them).

If this would be seen as an unacceptable user visible change of behavior
then we can go with the VMA flag but I would still prefer to not export
it to the userspace so that we have a way to change this in future.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213256

[Multipart message — attachments visible in raw view] — view raw

On Tue, 25 Aug 2015, Michal Hocko wrote:

> On Tue 25-08-15 10:29:02, Eric B Munson wrote:
> > On Tue, 25 Aug 2015, Michal Hocko wrote:
> [...]
> > > Considering the current behavior I do not thing it would be terrible
> > > thing to do what Konstantin was suggesting and populate only the full
> > > ranges in a best effort mode (it is done so anyway) and document the
> > > behavior properly.
> > > "
> > >        If the memory segment specified by old_address and old_size is
> > >        locked (using mlock(2) or similar), then this lock is maintained
> > >        when the segment is resized and/or relocated. As a consequence,
> > >        the amount of memory locked by the process may change.
> > > 
> > >        If the range is already fully populated and the range is
> > >        enlarged the new range is attempted to be fully populated
> > >        as well to preserve the full mlock semantic but there is no
> > >        guarantee this will succeed. Partially populated (e.g. created by
> > >        mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
> > >        so they are not populated on resize.
> > > "
> > 
> > You are proposing that mremap would scan the PTEs as Vlastimil has
> > suggested?
> 
> As Vlastimil pointed out this would be unnecessarily too costly. But I
> am wondering whether we should populate at all during mremap considering
> the full mlock semantic is not guaranteed anyway. Man page mentions only
> that the lock is maintained which will be true without population as
> well.
> 
> If somebody really depends on the current (and broken) implementation we
> can offer MREMAP_POPULATE which would do a best effort population. This
> would be independent on the locked state and would be usable for other
> mappings as well (the usecase would be to save page fault overhead by
> batching them).
> 
> If this would be seen as an unacceptable user visible change of behavior
> then we can go with the VMA flag but I would still prefer to not export
> it to the userspace so that we have a way to change this in future.

Would you drop your objections to the VMA flag if I drop the portions of
the patch that expose it to userspace?

The rework to not use the VMA flag is pretty sizeable and is much more
ugly IMO.  I know that you are not wild about using bit 30 of 32 for
this, but perhaps we can settle on not exporting it to userspace so we
can reclaim it if we really need it in the future?  I can teach the
folks here to check for size vs RSS of the locked mappings for stats on
lock on fault usage so from my point of view, the proc changes are not
necessary.

> -- 
> Michal Hocko
> SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1213605

On Tue 25-08-15 15:03:00, Eric B Munson wrote:
[...]
> Would you drop your objections to the VMA flag if I drop the portions of
> the patch that expose it to userspace?
> 
> The rework to not use the VMA flag is pretty sizeable and is much more
> ugly IMO.  I know that you are not wild about using bit 30 of 32 for
> this, but perhaps we can settle on not exporting it to userspace so we
> can reclaim it if we really need it in the future?

Yes, that would be definitely more acceptable for me. I do understand
that you are not wild about changing mremap behavior.

Anyway, I would really prefer if the vma flag was really used only at
few places - when we are clearing it along with VM_LOCKED (which could
be hidden in VM_LOCKED_CLEAR_MASK or something like that) and when we
decide whether the populate or not (this should be __mm_populate). But
maybe I am missing some call paths where gup is called unconditionally,
I haven't checked that.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213966

On 08/26/2015 09:20 AM, Michal Hocko wrote:
> On Tue 25-08-15 15:03:00, Eric B Munson wrote:
> [...]
>> Would you drop your objections to the VMA flag if I drop the portions of
>> the patch that expose it to userspace?
>>
>> The rework to not use the VMA flag is pretty sizeable and is much more
>> ugly IMO.  I know that you are not wild about using bit 30 of 32 for
>> this, but perhaps we can settle on not exporting it to userspace so we
>> can reclaim it if we really need it in the future?
>
> Yes, that would be definitely more acceptable for me. I do understand
> that you are not wild about changing mremap behavior.

+1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210250

On 08/19/2015 11:33 PM, Eric B Munson wrote:
> On Wed, 12 Aug 2015, Michal Hocko wrote:
>
>> On Sun 09-08-15 01:22:53, Eric B Munson wrote:
>>
>> I do not like this very much to be honest. We have only few bits
>> left there and it seems this is not really necessary. I thought that
>> LOCKONFAULT acts as a modifier to the mlock call to tell whether to
>> poppulate or not. The only place we have to persist it is
>> mlockall(MCL_FUTURE) AFAICS. And this can be handled by an additional
>> field in the mm_struct. This could be handled at __mm_populate level.
>> So unless I am missing something this would be much more easier
>> in the end we no new bit in VM flags would be necessary.
>>
>> This would obviously mean that the LOCKONFAULT couldn't be exported to
>> the userspace but is this really necessary?
>
> Sorry for the latency here, I was on vacation and am now at plumbers.
>
> I am not sure that growing the mm_struct by another flags field instead
> of using available bits in the vm_flags is the right choice.

I was making the same objection on one of the earlier versions and since 
you sticked with a new vm flag, I thought it doesn't matter, as we could 
change it later if we run out of bits. But now I realize that since you 
export this difference to userspace (and below you say that it's by 
request), we won't be able to change it later. So it's a more difficult 
choice.

> After this
> patch, we still have 3 free bits on 32 bit architectures (2 after the
> userfaultfd set IIRC).  The group which asked for this feature here
> wants the ability to distinguish between LOCKED and LOCKONFAULT regions
> and without the VMA flag there isn't a way to do that.
>
> Do we know that these last two open flags are needed right now or is
> this speculation that they will be and that none of the other VMA flags
> can be reclaimed?

I think it's the latter, we can expect that flags will be added rather 
than removed, as removal is hard or impossible.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web