Re: remap the .text segment into huge pages at run time - Mailing list pgsql-hackers

Hi,

On 2022-11-05 12:54:18 +0700, John Naylor wrote:
> On Sat, Nov 5, 2022 at 1:33 AM Andres Freund <andres@anarazel.de> wrote:
> > I hacked in a MADV_COLLAPSE (with setarch -R, so that I could just
> hardcode
> > the address / length), and it seems to work nicely.
> >
> > With the weird caveat that on fs one needs to make sure that the
> executable
> > doesn't reflinks to reuse parts of other files, and that the mold linker
> and
> > cp do... Not a concern on ext4, but on xfs. I took to copying the postgres
> > binary with cp --reflink=never
>
> What happens otherwise? That sounds like a difficult thing to guard against.

MADV_COLLAPSE fails, but otherwise things continue on. I think it's mostly an
issue on dev systems, not on prod systems, because there the files will be be
unpacked from a package or such.


> > On 2022-11-03 10:21:23 -0700, Andres Freund wrote:
> > > > - Add a "cold" __asm__ filler function that just takes up space,
> enough to
> > > > push the end of the .text segment over the next aligned boundary, or
> to
> > > > ~8MB in size.
> > >
> > > I don't understand why this is needed - as long as the pages are
> aligned to
> > > 2MB, why do we need to fill things up on disk? The in-memory contents
> are the
> > > relevant bit, no?
> >
> > I now assume it's because you either observed the mappings set up by the
> > loader to not include the space between the segments?
>
> My knowledge is not quite that deep. The iodlr repo has an example "hello
> world" program, which links with 8 filler objects, each with 32768
> __attribute((used)) dummy functions. I just cargo-culted that idea and
> simplified it. Interestingly enough, looking through the commit history,
> they used to align the segments via linker flags, but took it out here:
>
> https://github.com/intel/iodlr/pull/25#discussion_r397787559
>
> ...saying "I'm not sure why we added this". :/

That was about using a linker script, not really linker flags though.

I don't think the dummy functions are a good approach, there were plenty
things after it when I played with them.



> I quickly tried to align the segments with the linker and then in my patch
> have the address for mmap() rounded *down* from the .text start to the
> beginning of that segment. It refused to start without logging an error.

Hm, what linker was that? I did note that you need some additional flags for
some of the linkers.


> > With these flags the "R E" segments all start on a 0x200000/2MiB boundary
> and
> > are padded to the next 2MiB boundary. However the OS / dynamic loader only
> > maps the necessary part, not all the zero padding.
> >
> > This means that if we were to issue a MADV_COLLAPSE, we can before it do
> an
> > mremap() to increase the length of the mapping.
>
> I see, interesting. What location are you passing for madvise() and
> mremap()? The beginning of the segment (for me has .init/.plt) or an
> aligned boundary within .text?

I started postgres with setarch -R, looked at /proc/$pid/[s]maps to see the
start/end of the r-xp mapped segment.  Here's my hacky code, with a bunch of
comments added.

       void *addr = (void*) 0x555555800000;
       void *end = (void *) 0x555555e09000;
       size_t advlen = (uintptr_t) end - (uintptr_t) addr;

       const size_t bound = 1024*1024*2 - 1;
       size_t advlen_up = (advlen + bound - 1) & ~(bound - 1);
       void *r2;

       /*
        * Increase size of mapping to cover the tailing padding to the next
        * segment. Otherwise all the code in that range can't be put into
        * a huge page (access in the non-mapped range needs to cause a fault,
        * hence can't be in the huge page).
        * XXX: Should proably assert that that space is actually zeroes.
        */
       r2 = mremap(addr, advlen, advlen_up, 0);
       if (r2 == MAP_FAILED)
           fprintf(stderr, "mremap failed: %m\n");
       else if (r2 != addr)
           fprintf(stderr, "mremap wrong addr: %m\n");
       else
           advlen = advlen_up;

       /*
        * The docs for MADV_COLLAPSE say there should be at least one page
        * in the mapped space "for every eligible hugepage-aligned/sized
        * region to be collapsed". I just forced that. But probably not
        * necessary.
        */
       r = madvise(addr, advlen, MADV_WILLNEED);
       if (r != 0)
           fprintf(stderr, "MADV_WILLNEED failed: %m\n");

       r = madvise(addr, advlen, MADV_POPULATE_READ);
       if (r != 0)
           fprintf(stderr, "MADV_POPULATE_READ failed: %m\n");

       /*
        * Make huge pages out of it. Requires at least linux 6.1.  We could
        * fall back to MADV_HUGEPAGE if it fails, but it doesn't do all that
        * much in older kernels.
        */
#define MADV_COLLAPSE    25
       r = madvise(addr, advlen, MADV_COLLAPSE);
       if (r != 0)
           fprintf(stderr, "MADV_COLLAPSE failed: %m\n");


A real version would have to open /proc/self/maps and do this for at least
postgres' r-xp mapping. We could do it for libraries too, if they're suitably
aligned (both in memory and on-disk).

Greetings,

Andres Freund