Date: Thu, 11 Oct 2018 14:01:20 +1300 From: Thomas Munro <munro@ip9.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, alc@freebsd.org, mjg@freebsd.org Subject: Re: PostgresSQL vs super pages Message-ID: <CADLWmXWS6qjt02bxUkd7BewfhYw69at8OYe%2Bh15%2B1OCpnpi6ng@mail.gmail.com> In-Reply-To: <20181011001954.GV5335@kib.kiev.ua> References: <CADLWmXU=7QM-oHmY=TMAQanQE-dnXY4v74Zm1kkEz3Gc=ip21A@mail.gmail.com> <20181011001954.GV5335@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Oct 2018 at 13:20, Konstantin Belousov <kostikbel@gmail.com> wrote:
> On Thu, Oct 11, 2018 at 12:59:41PM +1300, Thomas Munro wrote:
> > shm_open("/PostgreSQL.1721888107",O_RDWR|O_CREAT|O_EXCL,0600) = 46 (0x2e)
> > ftruncate(46,0x400000) = 0 (0x0)
> Try to write zeroes instead of truncating.
> This should activate the fast path in the fault handler, and if the
> pages allocated for backing store of the shm object were from reservation,
> you should get superpage mapping on the first fault without promotion.
If you just write() to a newly shm_open()'d fd you get a return code
of 0 so I assume that doesn't work. If you ftruncate() to the desired
size first, then loop writing 8192 bytes of zeroes at a time, it
works. But still no super pages. I tried also with a write buffer of
2MB of zeroes, but still no super pages. I tried abandoning
shm_open() and instead using a mapped file, and still no super pages.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLWmXWS6qjt02bxUkd7BewfhYw69at8OYe%2Bh15%2B1OCpnpi6ng>