linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Jason Baron <jbaron@akamai.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Mel Gorman <mgorman@suse.de>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-api@vger.kernel.org, emunson@mgebm.net
Subject: Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
Date: Wed, 20 Jun 2018 13:00:22 +0200	[thread overview]
Message-ID: <20180620110022.GK13685@dhcp22.suse.cz> (raw)
In-Reply-To: <7a671035-92dc-f9c0-aa7b-ff916d556e82@akamai.com>

On Fri 15-06-18 15:36:07, Jason Baron wrote:
> 
> 
> On 06/13/2018 03:15 AM, Michal Hocko wrote:
> > On Wed 13-06-18 08:32:19, Vlastimil Babka wrote:
[...]
> >> BTW I didn't get why we should allow this for MADV_DONTNEED but not
> >> MADV_FREE. Can you expand on that?
> > 
> > Well, I wanted to bring this up as well. I guess this would require some
> > more hacks to handle the reclaim path correctly because we do rely on
> > VM_LOCK at many places for the lazy mlock pages culling.
> > 
> 
> The point of not allowing MADV_FREE on mlock'd pages for me was that
> with mlock and even MLOCK_ON_FAULT, one can always can always determine
> if a page is present or not (and thus avoid the major fault). Allowing
> MADV_FREE on lock'd pages breaks that assumption.

But once you have called MADV_FREE you cannot assume anything about the
content until you touch the memory again. So you can safely assume a
major fault for the worst case. Btw. why knowing whether you major fault
is important in the first place? What is an application going to do
about that information?
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-06-20 11:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-08 18:56 Jason Baron
2018-06-08 19:57 ` Andrew Morton
2018-06-08 20:55   ` Jason Baron
2018-06-09 11:51 ` kbuild test robot
2018-06-11  7:20 ` Michal Hocko
2018-06-11 14:51   ` Jason Baron
2018-06-11 15:03     ` Michal Hocko
2018-06-11 16:23       ` Jason Baron
2018-06-12  7:46         ` Michal Hocko
2018-06-12 14:11           ` Jason Baron
2018-06-13  6:32             ` Vlastimil Babka
2018-06-13  7:15               ` Michal Hocko
2018-06-13  7:51                 ` Vlastimil Babka
2018-06-13  8:37                   ` Michal Hocko
2018-06-15 19:36                 ` Jason Baron
2018-06-20 11:00                   ` Michal Hocko [this message]
2018-06-28 20:20                     ` Jason Baron
2018-06-13  9:13             ` Michal Hocko
2018-06-15 19:28               ` Jason Baron

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=20180620110022.GK13685@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=emunson@mgebm.net \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jbaron@akamai.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox