PostgresSQL vs super pages

Thomas Munro munro at ip9.org
Sun Oct 14 09:58:22 UTC 2018


On Sun, 14 Oct 2018 at 12:50, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Thu, Oct 11, 2018 at 02:01:20PM +1300, Thomas Munro wrote:
> > On Thu, 11 Oct 2018 at 13:20, Konstantin Belousov <kostikbel at 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.
>
> I did not quite scientific experiment, but you would need to try to find
> the differences between what I did and what you observe.  Below is the
> naive test program that directly implements my suggestion, and the
> output from the procstat -v for it after all things were set up.
>
...
> 98579        0x800e00000        0x801200000 rw- 1024 1030   3   0 --S- df

Huh.  Your program doesn't result in an S mapping on my laptop, but I
tried on an EC2 t2.2xlarge machine and there it promotes to S, even if
I comment out the write() loop (the loop that assigned to every byte
is enough).  The difference might be the amount of memory on the
system: on my 4GB laptop, it is very reluctant to use super pages (but
I have seen it do it, so I know it can).  On a 32GB system, it does it
immediately, and it works nicely for PostgreSQL too.  So perhaps my
problem is testing on a small RAM system, though I don't understand
why.


More information about the freebsd-hackers mailing list