Re: making use of large TLB pages

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: making use of large TLB pages
Date: 2002-09-25 17:07:19
Message-ID: 87vg4uxak8.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Neil Conway <neilc(at)samurai(dot)com> 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 <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-09-25 17:12:03 Re: Getting current transaction id
Previous Message scott.marlowe 2002-09-25 16:55:52 Re: PGXLOG variable worthwhile?