This is the mail archive of the
mailing list for the glibc project.
Re: Seeking consensus on BZ 16734
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, Daniel Colascione <dancol at dancol dot org>, Andrew Pinski <pinskia at gmail dot com>
- Date: Sun, 1 Feb 2015 20:46:06 -0800
- Subject: Re: Seeking consensus on BZ 16734
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobP_7jpdZUqSFmKCTFds6t8TTdnxfOfg2jCTr_TjvU+t2w at mail dot gmail dot com> <CAMe9rOrp6jCuPe4ZX-kdHdO_4_k-Dpf7ha-PxtCJmJLnL3K0-A at mail dot gmail dot com>
On Sun, Feb 1, 2015 at 8:09 PM, H.J. Lu <email@example.com> wrote:
>> Can we just do it?
> Do we have any current performance data on this?
I am not sure what performance data you want.
The application CPU will go up (calloc has to zero out space), kernel
CPU will go down (kernel would not have to zero out the same space).
It's clear that calloc()ing 8K is much cheaper than mmap()ing,
especially when there are 100s of threads.
On Sun, Feb 1, 2015 at 8:32 PM, <firstname.lastname@example.org> wrote:
> Note I think not using mmap is even better for targets that use page sizes besides 4k. Most distros for AARCH64 are going to be using 64k pages.
Yes, that's a nice additional argument.
> So wasting 63k worth of address space is not good, especially for ilp32.
AFAICT, the current BUFSIZ on x86_64 is 8192, so x86_64 is in fact not
wasting anything. But on a 64K page system, we surely are wasting a
lot of memory and kernel CPU cycles.