linux-kernel - Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting

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]

Date:	Thu, 11 Feb 2016 11:45:04 -0800
From:	Dave Hansen <dave@...1.net>
To:	Tim Chen <tim.c.chen@...ux.intel.com>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	Mel Gorman <mgorman@...hsingularity.net>,
	Vladimir Davydov <vdavydov@...tuozzo.com>,
	Konstantin Khlebnikov <koct9i@...il.com>
Subject: Re: [RFC PATCH 3/3] mm: increase scalability of global memory
 commitment accounting

On 02/11/2016 10:20 AM, Tim Chen wrote:
> The brk1 test is also somewhat pathologic.  It
> does nothing but brk which is unlikely for real workload.
> So we have to be careful when we are tuning our system
> behavior for brk1 throughput. We'll need to make sure
> whatever changes we made don't impact other more useful
> workloads adversely.

Yeah, there are *so* many alternatives to using brk() or mmap()/munmap()
frequently.

glibc has tunables to tune how tightly coupled malloc()/free() are with
virtual space allocation.  Raising those can reduce the brk() frequency.

There are also other allocators that take much larger chunks of virtual
address space and then "free" memory with MADV_FREE instead of brk().  I
think jemalloc does this, for instance.