Re: making use of large TLB pages - Mailing list pgsql-hackers

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@samurai.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073