On Sat, Nov 24, 2018 at 4:54 AM REIX, Tony <tony.r...@atos.net> wrote: > Here is a patch for enabling SystemV Shared Memory on AIX, for 64K or bigger > page size, rather than using MMAP shared memory, which is slower on AIX.
> We have tested this code with 64K pages and pgbench, on AIX 7.2 TL2 Power 9, > and it provided a maximum of +37% improvement. You also mentioned changing from XLC to GCC. Did you test the various changes in isolation? XLC->GCC, mmap->shmget, with/without SHM_LGPAGE. 37% is a bigger performance change than I expected from large pages, since reports from other architectures are single-digit percentage increases with pgbench -S. If just changing to GCC gives you a big speed-up, it could of course just be different/better code generation (though that'd be a bit sad for XLC), but I also wonder if the different atomics support in our tree could be implicated. > We'll test this code with Large Pages (SHM_LGPAGE | SHM_PIN | S_IRUSR | > S_IWUSR flags of shmget() ) ASAP. > > > However, I wanted first to get your comments about this change in order to > improve it for acceptance. I think we should respect the huge_pages GUC, as we do on Linux and Windows (since there are downsides to using large pages, maybe not everyone would want that). It could even be useful to allow different page sizes to be requested by GUC (I see that DB2 has an option to use 16GB pages -- yikes). It also seems like a good idea to have a shared_memory_type GUC as Andres proposed (see his link), instead of using a compile time option. I guess it was made a compile time option because nobody could imagine wanting to go back to SysV shm! (I'm still kinda surprised that MAP_ANONYMOUS memory can't be coaxed into large pages by environment variables or loader controls, since apparently other things like data segments etc apparently can, though I can't find any text that says that's the case and I have no AIX system). -- Thomas Munro http://www.enterprisedb.com
