From: Nicholas Miell <nmiell@comcast.net>
To: Suleiman Souhlal <ssouhlal@FreeBSD.org>
Cc: Ulrich Drepper <drepper@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrea Arcangeli <andrea@suse.de>,
Badari Pulavarty <pbadari@us.ibm.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, hugh@veritas.com,
dvhltc@us.ibm.com, linux-mm@kvack.org, blaisorblade@yahoo.it,
jdike@addtoit.com
Subject: Re: differences between MADV_FREE and MADV_DONTNEED
Date: Mon, 16 Jan 2006 17:04:07 -0800 [thread overview]
Message-ID: <1137459847.2842.6.camel@entropy> (raw)
In-Reply-To: <43CC3922.2070205@FreeBSD.org>
On Mon, 2006-01-16 at 16:24 -0800, Suleiman Souhlal wrote:
> Eric W. Biederman wrote:
> > As I recall the logic with DONTNEED was to mark the mapping of
> > the page clean so the page didn't need to be swapped out, it could
> > just be dropped.
> >
> > That is why they anonymous and the file backed cases differ.
> >
> > Part of the point is to avoid the case of swapping the pages out if
> > the application doesn't care what is on them anymore.
>
> Well, imho, MADV_DONTNEED should mean "I won't need this anytime soon",
> and MADV_FREE "I will never need this again".
>
POSIX doesn't have a madvise(), but it does have a posix_madvise(), with
flags defined as follows:
POSIX_MADV_NORMAL
Specifies that the application has no advice to give on its behavior
with respect to the specified range. It is the default characteristic if
no advice is given for a range of memory.
POSIX_MADV_SEQUENTIAL
Specifies that the application expects to access the specified range
sequentially from lower addresses to higher addresses.
POSIX_MADV_RANDOM
Specifies that the application expects to access the specified range
in a random order.
POSIX_MADV_WILLNEED
Specifies that the application expects to access the specified range
in the near future.
POSIX_MADV_DONTNEED
Specifies that the application expects that it will not access the
specified range in the near future.
Note that glibc forwards posix_madvise() directly to madvise(2), which
means that right now, POSIX conformant apps which use
posix_madvise(addr, len, POSIX_MADV_DONTNEED) are silently corrupting
data on Linux systems.
--
Nicholas Miell <nmiell@comcast.net>
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Miell <nmiell@comcast.net>
To: Suleiman Souhlal <ssouhlal@FreeBSD.org>
Cc: Ulrich Drepper <drepper@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrea Arcangeli <andrea@suse.de>,
Badari Pulavarty <pbadari@us.ibm.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, hugh@veritas.com,
dvhltc@us.ibm.com, linux-mm@kvack.org, blaisorblade@yahoo.it,
jdike@addtoit.com
Subject: Re: differences between MADV_FREE and MADV_DONTNEED
Date: Mon, 16 Jan 2006 17:04:07 -0800 [thread overview]
Message-ID: <1137459847.2842.6.camel@entropy> (raw)
In-Reply-To: <43CC3922.2070205@FreeBSD.org>
On Mon, 2006-01-16 at 16:24 -0800, Suleiman Souhlal wrote:
> Eric W. Biederman wrote:
> > As I recall the logic with DONTNEED was to mark the mapping of
> > the page clean so the page didn't need to be swapped out, it could
> > just be dropped.
> >
> > That is why they anonymous and the file backed cases differ.
> >
> > Part of the point is to avoid the case of swapping the pages out if
> > the application doesn't care what is on them anymore.
>
> Well, imho, MADV_DONTNEED should mean "I won't need this anytime soon",
> and MADV_FREE "I will never need this again".
>
POSIX doesn't have a madvise(), but it does have a posix_madvise(), with
flags defined as follows:
POSIX_MADV_NORMAL
Specifies that the application has no advice to give on its behavior
with respect to the specified range. It is the default characteristic if
no advice is given for a range of memory.
POSIX_MADV_SEQUENTIAL
Specifies that the application expects to access the specified range
sequentially from lower addresses to higher addresses.
POSIX_MADV_RANDOM
Specifies that the application expects to access the specified range
in a random order.
POSIX_MADV_WILLNEED
Specifies that the application expects to access the specified range
in the near future.
POSIX_MADV_DONTNEED
Specifies that the application expects that it will not access the
specified range in the near future.
Note that glibc forwards posix_madvise() directly to madvise(2), which
means that right now, POSIX conformant apps which use
posix_madvise(addr, len, POSIX_MADV_DONTNEED) are silently corrupting
data on Linux systems.
--
Nicholas Miell <nmiell@comcast.net>
--
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>
next prev parent reply other threads:[~2006-01-17 1:04 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-26 22:49 [RFC] madvise(MADV_TRUNCATE) Badari Pulavarty
2005-10-27 8:38 ` Andi Kleen
2005-10-27 13:17 ` Andrea Arcangeli
2005-10-27 15:00 ` Badari Pulavarty
2005-10-27 15:11 ` Andrea Arcangeli
2005-10-27 18:20 ` Andrew Morton
2005-10-27 18:35 ` Badari Pulavarty
2005-10-27 18:50 ` Andrew Morton
2005-10-27 19:40 ` Gerrit Huizenga
2005-10-27 19:56 ` Andi Kleen
2005-10-27 23:21 ` Darren Hart
2005-10-27 20:05 ` Theodore Ts'o
2005-10-27 20:16 ` Andrea Arcangeli
2005-10-28 1:42 ` Badari Pulavarty
2005-10-28 16:33 ` Theodore Ts'o
2005-10-27 20:22 ` Jeff Dike
2005-10-27 20:04 ` Andrea Arcangeli
2005-10-27 20:50 ` Andrew Morton
2005-10-27 21:37 ` Andrea Arcangeli
2005-10-27 22:23 ` Andrew Morton
2005-10-27 23:05 ` Badari Pulavarty
2005-10-27 23:16 ` Andrew Morton
2005-10-27 23:33 ` Peter Chubb
2005-10-28 0:22 ` Andrea Arcangeli
2005-10-28 0:32 ` Andrew Morton
2005-10-28 1:10 ` Andrea Arcangeli
2005-10-28 1:27 ` Badari Pulavarty
2005-10-28 2:00 ` Andrew Morton
2005-10-27 22:32 ` Badari Pulavarty
2005-10-27 23:28 ` Peter Chubb
2005-10-27 23:49 ` Andrew Morton
2005-10-27 23:56 ` Nathan Scott
2005-10-28 0:15 ` Andrea Arcangeli
2005-10-27 23:59 ` Peter Chubb
2005-10-28 3:46 ` Jeff Dike
2005-10-28 11:03 ` Blaisorblade
2005-10-28 13:29 ` Andrea Arcangeli
2005-10-28 16:56 ` Blaisorblade
2005-10-28 16:16 ` Badari Pulavarty
2005-10-28 18:40 ` Blaisorblade
2005-10-28 18:56 ` Badari Pulavarty
2005-10-29 0:35 ` Badari Pulavarty
2005-10-28 16:19 ` Badari Pulavarty
2005-10-28 17:10 ` Blaisorblade
2005-10-28 18:28 ` Jeff Dike
2005-10-28 18:44 ` Blaisorblade
2005-10-28 18:42 ` Jeff Dike
2005-10-28 18:54 ` Badari Pulavarty
2005-10-29 0:03 ` Badari Pulavarty
2005-10-29 2:51 ` Jeff Dike
2005-10-31 16:34 ` Badari Pulavarty
2005-10-31 19:15 ` Badari Pulavarty
2005-10-31 19:49 ` [RFC][PATCH] madvise(MADV_TRUNCATE) Badari Pulavarty
2005-11-01 0:05 ` Jeff Dike
2005-11-02 1:15 ` [PATCH] 2.6.14 patch for supporting madvise(MADV_FREE) Badari Pulavarty
2005-11-02 1:43 ` Andrea Arcangeli
2005-11-02 1:43 ` Andrea Arcangeli
2005-11-02 15:49 ` Badari Pulavarty
2005-11-02 15:49 ` Badari Pulavarty
2005-11-02 16:12 ` [PATCH] 2.6.14 patch for supporting madvise(MADV_REMOVE) Badari Pulavarty
2005-11-02 19:54 ` New bug in patch and existing Linux code - race with install_page() (was: Re: [PATCH] 2.6.14 patch for supporting madvise(MADV_REMOVE)) Blaisorblade
2005-11-02 19:54 ` Blaisorblade
2005-11-02 20:12 ` Hugh Dickins
2005-11-02 20:12 ` Hugh Dickins
2005-11-02 20:45 ` Hugh Dickins
2005-11-02 20:45 ` Hugh Dickins
2005-11-02 21:36 ` Badari Pulavarty
2005-11-02 21:36 ` Badari Pulavarty
2005-11-02 21:55 ` Hugh Dickins
2005-11-02 21:55 ` Hugh Dickins
2005-11-02 22:02 ` Badari Pulavarty
2005-11-02 22:02 ` Badari Pulavarty
2005-11-12 0:25 ` [PATCH] 2.6.14 patch for supporting madvise(MADV_REMOVE) Andrew Morton
2005-11-12 0:25 ` Andrew Morton
2005-11-12 0:34 ` Badari Pulavarty
2005-11-12 0:34 ` Badari Pulavarty
2005-11-12 1:43 ` Andrew Morton
2005-11-12 1:43 ` Andrew Morton
2005-11-12 4:41 ` Badari Pulavarty
2005-11-12 4:41 ` Badari Pulavarty
2006-01-16 13:06 ` differences between MADV_FREE and MADV_DONTNEED Andrea Arcangeli
2006-01-16 13:06 ` Andrea Arcangeli
2006-01-16 16:02 ` Suleiman Souhlal
2006-01-16 16:02 ` Suleiman Souhlal
2006-01-16 16:28 ` Andrea Arcangeli
2006-01-16 16:28 ` Andrea Arcangeli
2006-01-16 17:03 ` Suleiman Souhlal
2006-01-16 17:03 ` Suleiman Souhlal
2006-01-16 17:24 ` Andrea Arcangeli
2006-01-16 17:24 ` Andrea Arcangeli
2006-01-16 21:43 ` Eric W. Biederman
2006-01-16 21:43 ` Eric W. Biederman
2006-01-17 0:24 ` Suleiman Souhlal
2006-01-17 0:24 ` Suleiman Souhlal
2006-01-17 1:04 ` Nicholas Miell [this message]
2006-01-17 1:04 ` Nicholas Miell
2006-01-17 12:43 ` Christoph Hellwig
2006-01-17 12:43 ` Christoph Hellwig
2006-01-17 18:23 ` Eric W. Biederman
2006-01-17 18:23 ` Eric W. Biederman
2006-01-17 22:55 ` Nicholas Miell
2006-01-17 22:55 ` Nicholas Miell
2007-03-01 18:11 ` Samuel Thibault
2007-03-01 18:11 ` Samuel Thibault
2006-01-17 19:06 ` Badari Pulavarty
2006-01-17 19:06 ` Badari Pulavarty
2006-01-17 1:06 ` Blaisorblade
2006-01-17 1:06 ` Blaisorblade
2006-01-17 1:33 ` Andrea Arcangeli
2006-01-17 1:33 ` Andrea Arcangeli
2005-11-12 0:34 ` [PATCH] 2.6.14 patch for supporting madvise(MADV_REMOVE) Andrew Morton
2005-11-12 0:34 ` Andrew Morton
2005-10-28 17:55 ` [RFC] madvise(MADV_TRUNCATE) Blaisorblade
2005-10-28 21:23 ` Theodore Ts'o
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=1137459847.2842.6.camel@entropy \
--to=nmiell@comcast.net \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=blaisorblade@yahoo.it \
--cc=drepper@redhat.com \
--cc=dvhltc@us.ibm.com \
--cc=ebiederm@xmission.com \
--cc=hugh@veritas.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbadari@us.ibm.com \
--cc=ssouhlal@FreeBSD.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.