Re: pgsql: Introduce pg_shmem_allocations_numa view
От
Tomas Vondra
Тема
Re: pgsql: Introduce pg_shmem_allocations_numa view
Дата
Msg-id
e4fe7d48-668b-4b38-8a69-da5f5b900be7@vondra.me
Ответ на
Re: pgsql: Introduce pg_shmem_allocations_numa view (Christoph Berg)
Список
Дерево обсуждения
Re: pgsql: Introduce pg_shmem_allocations_numa view Tomas Vondra <tomas@vondra.me>
Re: pgsql: Introduce pg_shmem_allocations_numa view Christoph Berg <myon@debian.org>
Re: pgsql: Introduce pg_shmem_allocations_numa view Tomas Vondra <tomas@vondra.me>
Re: pgsql: Introduce pg_shmem_allocations_numa view Tomas Vondra <tomas@vondra.me>
Re: pgsql: Introduce pg_shmem_allocations_numa view Andres Freund <andres@anarazel.de>
Re: pgsql: Introduce pg_shmem_allocations_numa view Tomas Vondra <tomas@vondra.me>
On 6/25/25 11:00, Christoph Berg wrote: > Re: Bertrand Drouvot >> +/* >> + * Work around Linux kernel bug in 32-bit compat mode: do_pages_stat() has >> + * incorrect pointer arithmetic for more than DO_PAGES_STAT_CHUNK_NR pages. >> + */ >> +#if SIZEOF_SIZE_T == 4 > > I was also missing it in my suggested patch draft, but this should > probably include #ifdef __linux__. > > > Re: Tomas Vondra >> +#ifdef USE_VALGRIND >> + >> +static inline void >> +pg_numa_touch_mem_if_required(uint64 tmp, char *ptr) > > Stupid question, if this function gets properly inlined, why not > always use it as there should be no performance difference vs using a > macro? > TBH I'm not 100% sure it works correctly, I need to check it actually touches the memory etc. It's possible it was discussed in one of the earlier NUMA threads, and there are reasons to do a macro. I also dislike the ifdefs because it adds subtle differences between the "normal" code and the code tested with valgrind. So just having the inlined function would be "nicer". regards -- Tomas Vondra
В списке pgsql-hackers по дате отправления
От: Peter Eisentraut
Дата:
От: Andy Fan
Дата: