| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Introduce pg_shmem_allocations_numa view |
| Date: | 2025-06-24 15:30:02 |
| Message-ID: | aFrEesaN9YlV0RrJ@msg.df7cb.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Re: Tomas Vondra
> If it's a reliable fix, then I guess we can do it like this. But won't
> that be a performance penalty on everyone? Or does the system split the
> array into 16-element chunks anyway, so this makes no difference?
There's still the overhead of the syscall itself. But no idea how
costly it is to have this 16-step loop in user or kernel space.
We could claim that on 32-bit systems, shared_buffers would be smaller
anyway, so there the overhead isn't that big. And the step size should
be larger (if at all) on 64-bit.
> Anyway, maybe we should start by reporting this to the kernel people. Do
> you want me to do that, or shall one of you take care of that? I suppose
> that'd be better, as you already wrote a fix / know the code better.
Submitted: https://marc.info/?l=linux-mm&m=175077821909222&w=2
Christoph
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2025-06-24 17:42:58 | pgsql: Improve jumble squashing through CoerceViaIO and RelabelType |
| Previous Message | Tomas Vondra | 2025-06-24 15:04:00 | Re: pgsql: Introduce pg_shmem_allocations_numa view |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2025-06-24 15:48:46 | Re: Make COPY format extendable: Extract COPY TO format implementations |
| Previous Message | Fujii Masao | 2025-06-24 15:26:12 | pg_dumpall dumps global objects with --statistics-only or --no-schema |