From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@lists.postgresql.org,
 Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tv@fuzzy.cz>
Subject: Re: Use generation context to speed up tuplesorts
Date: Fri, 17 Dec 2021 15:00:25 +0100
Message-ID: <4776839.iZASKD2KPV@aivenronan>
Organization: aiven
In-Reply-To: <fed46811-b62a-9f9b-343f-6d46fe1f0b57@enterprisedb.com>
References: 
 <CAApHDvoH4ASzsAOyHcxkuY01Qf++8JJ0paw+03dk+W25tQEcNQ@mail.gmail.com>
 <7285172.GXAFRqVoOG@aivenronan>
 <fed46811-b62a-9f9b-343f-6d46fe1f0b57@enterprisedb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
 <https://www.postgresql.org/message-id/4776839.iZASKD2KPV%40aivenronan>
Precedence: bulk

Le vendredi 17 d=E9cembre 2021, 14:39:10 CET Tomas Vondra a =E9crit :
> I wasn't really suggesting to investigate those other allocators in this
> patch - it seems like a task requiring a pretty significant amount of
> work/time. My point was that we should make it reasonably easy to add
> tweaks for those other environments, if someone is interested enough to
> do the legwork.
>=20
> >> 2) In fact, I wonder if different glibc versions behave differently?
> >> Hopefully it's not changing that much, though. Ditto kernel versions,
> >> but the mmap/sbrk interface is likely more stable. We can test this.
> >=20
> > That could be tested, yes. As a matter of fact, a commit removing the
> > upper
> > limit for MALLOC_MMAP_THRESHOLD has just been committed yesterday to
> > glibc,
> > which means we can service much bigger allocation without mmap.
>=20
> Yeah, I noticed that commit too. Most systems stick to one glibc
> version, so it'll take time to reach most systems. Let's continue with
> just one glibc version and then maybe test other versions.

Yes, I also need to figure out how to detect we're using glibc as I'm not v=
ery=20
familiar with configure.=20

>=20
> >> 3) If we bump the thresholds, won't that work against reusing the
> >> memory? I mean, if we free a whole block (from any allocator we have),
> >> glibc might return it to kernel, depending on mmap threshold value. It=
's
> >> not guaranteed, but increasing the malloc thresholds will make that ev=
en
> >> less likely. So we might just as well increase the minimum block size,
> >> with about the same effect, no?
> >=20
> > It is my understanding that malloc will try to compact memory by moving=
 it
> > around. So the memory should be actually be released to the kernel at s=
ome
> > point. In the meantime, malloc can reuse it for our next invocation (wh=
ich
> > can be in a different memory context on our side).
> >=20
> > If we increase the minimum block size, this is memory we will actually
> >=20
> > reserve, and it will not protect us against the ramping-up behaviour:
> >  - the first allocation of a big block may be over mmap_threshold, and
> >  serviced>=20
> > by an expensive mmap
> >=20
> >  - when it's free, the threshold is doubled
> >  - next invocation is serviced by an sbrk call
> >  - freeing it will be above the trim threshold, and it will be returned.
> >=20
> > After several "big" allocations, the thresholds will raise to their
> > maximum
> > values (well, it used to, I need to check what happens with that latest
> > patch of glibc...)
> >=20
> > This will typically happen several times as malloc doubles the threshold
> > each time. This is probably the reason quadrupling the block sizes was
> > more effective.
>=20
> Hmmm, OK. Can we we benchmark the case with large initial block size, at
> least for comparison?

The benchmark I called "fixed" was with a fixed block size of=20
ALLOCSET_DEFAULT_MAXSIZE (first proposed patch) and showed roughly the same=
=20
performance profile as the growing blocks + malloc tuning.
But if  I understand correctly, you implemented the growing blocks logic af=
ter=20
concerns about wasting memory with a constant large block size. If we tune=
=20
malloc, that memory would not be wasted if we don't alloc it, just not=20
released as eagerly when it's allocated.=20

Or do you want a benchmark with an even bigger initial block size ? With th=
e=20
growing blocks patch with a large initial size ? I can run either, I just w=
ant=20
to understand what is interesting to you.

One thing that would be interesting would be to trace the total amount of=20
memory allocated in the different cases. This is something I will need to d=
o=20
anyway when I propose that patch;=20

Best regards,

=2D-=20
Ronan Dunklau