Re: making use of large TLB pages

I haven't been following this thread. Can someone answer:

Is TLB Linux-only?
Why use it and non SysV memory?
Is it a lot of code?

---------------------------------------------------------------------------

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > If we used a key that would remain the same between runs of the
> > postmaster, this should ensure that there isn't a possibility of two
> > independant sets of backends operating on the same data dir. The most
> > logical way to do this IMHO would be to just hash the data dir, but I
> > suppose the current method of using the port number should work as
> > well.
>
> You should stick as closely as possible to the key logic currently used
> for SysV shmem keys. That logic is intended to cope with the case where
> someone else is already using the key# that we initially generate, as
> well as the case where we discover a collision with a pre-existing
> backend set. (We tell the difference by looking for a magic number at
> the start of the shmem segment.)
>
> Note that we do not assume the key is the same on each run; that's why
> we store it in postmaster.pid.
>
> > (1) call sys_alloc_hugepages() without IPC_EXCL. If it returns
> > an error, we're in the clear: there's no page matching
> > that key. If it returns a pointer to a previously existing
> > segment, panic: it is very likely that there are some
> > orphaned backends still active.
>
> s/panic/and the PG magic number appears in the segment header, panic/
>
> > - if we're compiling on a Linux system but the kernel headers
> > don't define the syscalls we need, use some reasonable
> > defaults (e.g. the syscall numbers for the current hugepage
> > syscalls in Linux 2.5)
>
> I think this is overkill, and quite possibly dangerous. If we don't see
> the symbols then don't try to compile the code.
>
> On the whole it seems that this allows a very nearly one-to-one mapping
> to the existing SysV functionality. We don't have the "number of
> connected processes" syscall, perhaps, but we don't need it: if a
> hugepages segment exists we can assume the number of connected processes
> is greater than 0, and that's all we really need to know.
>
> I think it's okay to stuff this support into the existing
> port/sysv_shmem.c file, rather than make a separate file (particularly
> given your point that we have to be able to fall back to SysV calls at
> runtime). I'd suggest reorganizing the code in that file slightly to
> separate the actual syscalls from the controlling logic in
> PGSharedMemoryCreate(). Probably also will have to extend the API for
> PGSharedMemoryIsInUse() and RecordSharedMemoryInLockFile() to allow
> three fields to be recorded in postmaster.pid, not two --- you'll want
> a boolean indicating whether the stored key is for a SysV or hugepage
> segment.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073