All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>
To: Eric B Munson <emunson-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>,
	Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
	"Kirill A. Shutemov"
	<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
Date: Thu, 20 Aug 2015 09:53:50 +0200	[thread overview]
Message-ID: <55D5878E.5030206@suse.cz> (raw)
In-Reply-To: <20150819213345.GB4536-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Eric B Munson <emunson@akamai.com>, Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-mm@kvack.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
Date: Thu, 20 Aug 2015 09:53:50 +0200	[thread overview]
Message-ID: <55D5878E.5030206@suse.cz> (raw)
In-Reply-To: <20150819213345.GB4536@akamai.com>

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, 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: Vlastimil Babka <vbabka@suse.cz>
To: Eric B Munson <emunson@akamai.com>, Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-mm@kvack.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
Date: Thu, 20 Aug 2015 09:53:50 +0200	[thread overview]
Message-ID: <55D5878E.5030206@suse.cz> (raw)
In-Reply-To: <20150819213345.GB4536@akamai.com>

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.


  parent reply	other threads:[~2015-08-20  7:53 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-09  5:22 [PATCH v7 0/6] Allow user to request memory to be locked on page fault Eric B Munson
2015-08-09  5:22 ` Eric B Munson
2015-08-09  5:22 ` Eric B Munson
2015-08-09  5:22 ` [PATCH v7 1/6] mm: mlock: Refactor mlock, munlock, and munlockall code Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-12  9:42   ` Michal Hocko
2015-08-12  9:42     ` Michal Hocko
2015-08-09  5:22 ` [PATCH v7 2/6] mm: mlock: Add new mlock system call Eric B Munson
2015-08-09  5:22 ` Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-12  9:45   ` Michal Hocko
2015-08-12  9:45   ` Michal Hocko
2015-08-12  9:45     ` Michal Hocko
2015-08-12  9:45     ` Michal Hocko
2015-08-12  9:45     ` Michal Hocko
2015-08-12  9:45     ` Michal Hocko
2015-08-09  5:22 ` [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-12 11:59   ` Michal Hocko
2015-08-12 11:59     ` Michal Hocko
2015-08-19 21:33     ` Eric B Munson
     [not found]       ` <20150819213345.GB4536-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-20  7:53         ` Vlastimil Babka [this message]
2015-08-20  7:53           ` Vlastimil Babka
2015-08-20  7:53           ` Vlastimil Babka
2015-08-20  7:56         ` Michal Hocko
2015-08-20  7:56           ` Michal Hocko
2015-08-20  7:56           ` Michal Hocko
2015-08-20 17:03           ` Eric B Munson
     [not found]             ` <20150820170309.GA11557-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-21  7:25               ` Michal Hocko
2015-08-21  7:25                 ` Michal Hocko
2015-08-21  7:25                 ` Michal Hocko
     [not found]                 ` <20150821072552.GF23723-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-08-21 18:31                   ` Eric B Munson
2015-08-21 18:31                     ` Eric B Munson
     [not found]                     ` <20150821183132.GA12835-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-24 10:17                       ` Konstantin Khlebnikov
2015-08-24 10:17                         ` Konstantin Khlebnikov
2015-08-24 10:17                         ` Konstantin Khlebnikov
2015-08-24 13:30                         ` Vlastimil Babka
2015-08-24 13:30                           ` Vlastimil Babka
     [not found]                           ` <55DB1C77.8070705-AlSwsSmVLrQ@public.gmane.org>
2015-08-24 13:50                             ` Konstantin Khlebnikov
2015-08-24 13:50                               ` Konstantin Khlebnikov
2015-08-24 13:50                               ` Konstantin Khlebnikov
     [not found]                               ` <CALYGNiNuZgQFzZ+_dQsPOvSJAX7QfZ38zbabn4wRc=oC5Lb9wA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-24 14:27                                 ` Vlastimil Babka
2015-08-24 14:27                                   ` Vlastimil Babka
2015-08-24 14:27                                   ` Vlastimil Babka
2015-08-24 15:09                                   ` Eric B Munson
2015-08-24 15:46                                     ` Konstantin Khlebnikov
2015-08-24 15:46                                       ` Konstantin Khlebnikov
2015-08-24 15:55                                       ` Eric B Munson
     [not found]                                         ` <20150824155503.GB17005-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-24 16:22                                           ` Konstantin Khlebnikov
2015-08-24 16:22                                             ` Konstantin Khlebnikov
2015-08-24 16:22                                             ` Konstantin Khlebnikov
2015-08-24 17:00                                             ` Eric B Munson
     [not found]                                               ` <20150824170028.GC17005-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-24 18:53                                                 ` Konstantin Khlebnikov
2015-08-24 18:53                                                   ` Konstantin Khlebnikov
2015-08-24 18:53                                                   ` Konstantin Khlebnikov
     [not found]                                                   ` <CALYGNiO3r9Yx7xeS-rZ_nVCR+BRP4d0-Fnd0omkBDdh1ftnExg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-24 20:26                                                     ` Eric B Munson
2015-08-24 20:26                                                       ` Eric B Munson
2015-08-25 13:41                       ` Michal Hocko
2015-08-25 13:41                         ` Michal Hocko
2015-08-25 13:41                         ` Michal Hocko
2015-08-25 13:55                         ` Vlastimil Babka
2015-08-25 13:55                           ` Vlastimil Babka
2015-08-25 14:29                           ` Michal Hocko
2015-08-25 14:29                             ` Michal Hocko
     [not found]                         ` <20150825134154.GB6285-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-08-25 13:58                           ` Konstantin Khlebnikov
2015-08-25 13:58                             ` Konstantin Khlebnikov
2015-08-25 13:58                             ` Konstantin Khlebnikov
2015-08-25 14:29                         ` Eric B Munson
     [not found]                           ` <20150825142902.GF17005-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-25 18:58                             ` Michal Hocko
2015-08-25 18:58                               ` Michal Hocko
2015-08-25 18:58                               ` Michal Hocko
2015-08-25 19:03                               ` Eric B Munson
     [not found]                                 ` <20150825190300.GG17005-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
2015-08-26  7:20                                   ` Michal Hocko
2015-08-26  7:20                                     ` Michal Hocko
2015-08-26  7:20                                     ` Michal Hocko
2015-08-26 15:35                                     ` Vlastimil Babka
2015-08-26 15:35                                       ` Vlastimil Babka
2015-08-09  5:22 ` [PATCH v7 4/6] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-09  5:22 ` [PATCH v7 5/6] selftests: vm: Add tests for lock on fault Eric B Munson
2015-08-09  5:22   ` Eric B Munson
2015-08-09  5:22 ` [PATCH v7 6/6] mips: Add entry for new mlock2 syscall Eric B Munson
2015-08-09  5:22   ` Eric B Munson

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=55D5878E.5030206@suse.cz \
    --to=vbabka-alswssmvlrq@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=corbet-T1hC0tSOHrs@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=emunson-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org \
    --cc=kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /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.