Re: failed NUMA pages inquiry status: Operation not permitted
| От | Tomas Vondra |
|---|---|
| Тема | Re: failed NUMA pages inquiry status: Operation not permitted |
| Дата | |
| Msg-id | 20d4c8a3-a402-4426-a912-8261e8923adf@vondra.me обсуждение исходный текст |
| Ответ на | Re: failed NUMA pages inquiry status: Operation not permitted (Christoph Berg <myon@debian.org>) |
| Список | pgsql-hackers |
On 10/16/25 16:54, Christoph Berg wrote: > Re: Tomas Vondra >> It's probably more about the kernel version. What kernels are used by >> these systems? > > It's the very same kernel, just different docker containers on the > same system. I did not investigate yet where the problem is coming > from, different libnuma versions seemed like the best bet. > > Same (differing) results on both these systems: > Linux turing 6.16.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.16.7-1 (2025-09-11) x86_64 GNU/Linux > Linux jenkins 6.1.0-39-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.148-1 (2025-08-26) x86_64 GNU/Linux > Hmmm. Those seem like relatively recent kernels. >> Not sure how would that work. It seems this is some sort of permission >> check in numa_move_pages, that's not what pg_numa_available does. Also, >> it may depending on the page queried (e.g. whether it's exclusive or >> shared by multiple processes). > > It's probably the lack of some process capability in that environment. > Maybe there is a way to query that, but I don't know much about that > yet. > move_page() manpage mentions PTRACE_MODE_READ_REALCREDS (man ptrace) so maybe that's it. -- Tomas Vondra
В списке pgsql-hackers по дате отправления: