This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc - cache locality - TLB
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, Torvald Riegel <triegel at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at suse dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Mon, 23 Dec 2013 14:17:06 +0530
- Subject: Re: malloc - cache locality - TLB
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <1386688619 dot 23049 dot 3215 dot camel at triegel dot csb> <20131220022411 dot GA26981 at domone dot podge> <20131220160915 dot GA7826 at domone dot podge> <20131220162116 dot GP24286 at brightrain dot aerifal dot cx> <20131220190051 dot GA9523 at domone dot podge> <20131220224337 dot GS24286 at brightrain dot aerifal dot cx>
On Fri, Dec 20, 2013 at 05:43:38PM -0500, Rich Felker wrote:
> No it doesn't. That's the old, nasty, should-be-deprecated
> non-transparent way. With transparent huge pages enabled in the
> kernel, the kernel simply uses them when you call mmap without
> userspace ever having to be aware of it.
A minor nit: the kernel doesn't directly use huge pages for large
allocations. i believe the initial page faults are serviced using
regular pages and there's a separate kernel thread that does
consolidation of those pages into huge pages using some kind of
heuristic. But yeah, the process (true to its name) is completely
transparent.
Siddhesh