linux-kernel - Re: [PATCH] lazy freeing of memory through MADV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a36005b50704201424q3c07d457m6b2c468ff8a826c7@mail.gmail.com>
Date:	Fri, 20 Apr 2007 14:24:55 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Rik van Riel" <riel@...hat.com>,
	"Jakub Jelinek" <jakub@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCH] lazy freeing of memory through MADV_FREE 2/2

On 4/20/07, Andrew Morton <akpm@...ux-foundation.org> wrote:
> OK, we need to flesh this out a lot please.  People often get confused
> about what our MADV_DONTNEED behaviour is.

Well, there's not really much to flesh out.  The current MADV_DONTNEED
is useful in some situations.  The behavior cannot be changed, even
glibc will rely on it for the case when MADV_FREE is not supported.

What might be nice to have is to have a POSIX-compliant
POSIX_MADV_DONTNEED implementation.  We currently do nothing which is
OK since no test suite can detect that.  But some code might want to
use the real behavior and we're missing an optimization possibility.

Just for reference: the MADV_CURRENT behavior is to throw away data in
the range.  The POSIX_MADV_DONTNEED behavior is to never lose data.
I.e., file backed data is written back, anon data is at most swapped
out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/