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