Re: pgsql: Introduce pg_shmem_allocations_numa view - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: pgsql: Introduce pg_shmem_allocations_numa view
Date
Msg-id aFrEesaN9YlV0RrJ@msg.df7cb.de
Whole thread Raw
In response to Re: pgsql: Introduce pg_shmem_allocations_numa view  (Tomas Vondra <tomas@vondra.me>)
Responses Re: pgsql: Introduce pg_shmem_allocations_numa view
Re: pgsql: Introduce pg_shmem_allocations_numa view
List 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



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Simplify VM counters in vacuum code
Next
From: Masahiko Sawada
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations