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]
Date:	Thu, 3 Jan 2013 09:19:08 -0800
From:	Sanjay Ghemawat <>
To:	Minchan Kim <>
Cc:	Andrew Morton <>,,,
	Michael Kerrisk <>,
	Arun Sharma <>, Paul Turner <>,
	David Rientjes <>,
	John Stultz <>,
	Christoph Lameter <>,
	Android Kernel Team <>,
	Robert Love <>, Mel Gorman <>,
	Hugh Dickins <>,
	Dave Hansen <>,
	Rik van Riel <>,
	Dave Chinner <>, Neil Brown <>,
	Mike Hommey <>, Taras Glek <>,
	KOSAKI Motohiro <>,
	KAMEZAWA Hiroyuki <>
Subject: Re: [RFC v5 0/8] Support volatile for anonymous range

On Wed, Jan 2, 2013 at 8:27 PM, Minchan Kim <> wrote:
> This is still RFC because we need more input from user-space
> people, more stress test, design discussion about interface/reclaim

Speaking as one of the authors of tcmalloc, I don't see any particular
need for this new system call for tcmalloc.  We are fine using
madvise(MADV_DONTNEED) and don't notice any significant
performance issues caused by it.  Background: we throttle how
quickly we release memory back to the system (1-10MB/s), so
we do not call madvise() very much, and we don't end up reusing
madvise-ed away pages at a fast rate. My guess is that we won't
see large enough application-level performance improvements to
cause us to change tcmalloc to use this system call.

> - What's different with madvise(DONTNEED)?
>   System call semantic
>   DONTNEED makes sure user always can see zero-fill pages after
>   he calls madvise while mvolatile can see old data or encounter

Do you need a new system call for this?  Why not just a new flag to madvise
with weaker guarantees than zero-filling?  All of the implementation changes
you point out below could be triggered from that flag.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists