Re: Problems with huge_pages and IBM Power8 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Problems with huge_pages and IBM Power8
Date
Msg-id 20160412202010.g3tofgl6jwyzf2uj@alap3.anarazel.de
Whole thread Raw
In response to Problems with huge_pages and IBM Power8  (reiner peterke <zedaardv@drizzle.com>)
Responses Re: Problems with huge_pages and IBM Power8
Re: Problems with huge_pages and IBM Power8
Re: Problems with huge_pages and IBM Power8
List pgsql-hackers
On 2016-04-12 21:58:14 +0200, reiner peterke wrote:
> Hi
> 
> We have been doing some testing with Postgres (9.5.2) compiled on a Power8 running Centos 7
> 
> When working with huge_pages, we initially got this error.
> 
> munmap(0x3efbe4000000) failed: Invalid argument

*munmap*, not mmap failed? that's odd; because there the hugepagesize
shouldn't have much of an influence. If something fails it should be the
initial mmap.  Could you show a strace of a failed start with an
unmodified postgres?

> after a bit of investigation we noticed that hugepagesize is har coded
> to 2MB

Note it's not actually hardcoded to some size. It's just about rounding
the size to a multiple of 2MB due to an older kernel bug:    /*     * Round up the request size to a suitable large
value.    *     * Some Linux kernel versions are known to have a bug, which causes     * mmap() with MAP_HUGETLB to
failif the request size is not a     * multiple of any supported huge page size. To work around that, we     * round up
therequest size to nearest 2MB. 2MB is the most common     * huge page page size on affected systems.
 


> Going further, we tried testing hugepages also on Ubuntu 16.04, also on the power8.  On Ubuntu Postgres did not like
thehugepages at all (set also to 16MB)  and consistently crashed.
 

> Looking for some insight into this issue.  the error from the postgres
> log on ubuntu is below.  It apperas to be related to semephores.

I've a bit of a hard time believing that this is related to huge pages.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Next
From: Pavel Stehule
Date:
Subject: Re: raw output from copy