Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'd like to enable PostgreSQL to use large TLB pages, if the OS
> > and processor support them.
>
> Hmm ... it seems interesting, but I'm hesitant to do a lot of work
> to support something that's only available on one hardware-and-OS
> combination.
True; further, I personally find the current API a little
cumbersome. For example, we get 4MB pages on Solaris with a few lines
of code:
#if defined(solaris) && defined(__sparc__) /* use intimate shared
memory on SPARC Solaris */ memAddress = shmat(shmid, 0,
SHM_SHARE_MMU);
But given that
(a) Linux on x86 is probably our most popular platform
(b) Every x86 since the Pentium has supported large pages
(c) Other archs, like IA64 and SPARC, also support large pages
I think it's worthwhile implementing this, if possible.
> I trust it at least supports inheriting the page mapping over a
> fork()?
I'll check on this, but I'm pretty sure that it does.
> The SysV API provides a reliable interlock to prevent this scenario:
> we read the old shared memory block ID from the old postmaster's
> postmaster.pid file, and look to see if that block (a) still exists
> and (b) still has attached processes (presumably backends).
If the postmaster is starting up and the segment still exists, could
we assume that's an error condition, and force the admin to manually
fix it? It does make the system less robust, but I'm suspicious of any
attempts to automagically fix a situation in which we *know* something
has gone seriously wrong...
Another possibility might be to still allocate a small SysV shmem
area, and use that to provide the interlock, while we allocate the
buffer area using sys_alloc_hugepages. That's somewhat of a hack, but
I think it would resolve the interlock problem, at least.
> Any ideas for better answers?
Still scratching my head on this one, and I'll let you know if I think
of anything better.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
