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 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
Дата:
FAQ