This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc - cache locality - TLB

On Fri, Dec 20, 2013 at 11:21:16AM -0500, Rich Felker wrote:
> On Fri, Dec 20, 2013 at 05:09:15PM +0100, OndÅej BÃlka wrote:
> > As linux supported since 2003 huge pages we could try to use these.
> Transparentt huge pages are the only sane way to use them, and they're
> already supported for huge malloc calls serviced by mmap.

This needs to invoke libhugetlbfs which is extra dependency. A
transparency is not wanted as we need to distinguish cases where these
pages will be used versus where not.

>  The kernel
> could also opt to use huge pages for heap ranges consisting of many
> independent allocations, but this would probably be a pessimization in
> the general case because it precludes fine-grained swapping of unused
> data and like you mentioned has ridiculous overhead.
Swapping is secondary concern, you cannot save more than is in huge
pages, data there tends to get accessed randomly in unpredictable
intervals which could cause dos by excessive disk seeks.

There is no overhead when all pages would eventualy get used. 

In short-lived applications these could improve perfornmace by avoiding
minor faults, adding MAP_HUGETLB in following example improves running
time by around 10%.

#include <sys/mman.h>
#include <stdlib.h>
int main()
  int i;
  char *x = mmap (NULL, 30 * 1 << 21, PROT_READ | PROT_WRITE,
  for (i=0; i < 30 * (1 << 21); i += 4096)
       x[i] = 42;

If there were 128k pages, they would be more useful as these decrease
overhead nearly as well as huge ones and have wider application range.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]