Rohit Seth recently added support for the use of large TLB pages on Linux if the processor architecture supports them (I believe the SPARC, IA32, and IA64 have hugetlb support, more archs will probably be added). The patch was merged into Linux 2.5.36, so it will more than likely be in Linux 2.6. For more information on large TLB pages and why they are generally viewed to improve database performance, see here:
http://lwn.net/Articles/6535/ (the patch this refers to is an earlier implementation, I believe, but the idea is the same) http://lwn.net/Articles/10293/ (item #4) I'd like to enable PostgreSQL to use large TLB pages, if the OS and processor support them. In talking to the author of the TLB patches for Linux (Rohit Seth), he described the current API: ====== 1) Only two system calls. These are: sys_alloc_hugepages(int key, unsigned long addr, unsigned long len, int prot, int flag) sys_free_hugepages(unsigned long addr) Key will be equal to zero if user wants these huge pages as private. A positive int value will be used for unrelated apps to share the same physical huge pages. addr is the user prefered address. The kernel may decide to allocate a different virtual address (depending on availability and alignment factors). len is the requested size of memory wanted by user app. prot could get the value of PROT_READ, PROT_WRITE, PROT_EXEC flag: The only allowed value right now is IPC_CREAT, which in case of shred hugepages (across processes) tells the kernel to create a new segment if none is already created. If this flag is not provided and there is no hugepage segment corresponding to the "key" then ENOENT is returned. More like on the lines of IPC_CREAT flag for shmget routine. On success sys_alloc_hugepages returns the virtual address allocated by kernel. ===== So as I understand it, we would basically replace the calls to shmget(), shmdt(), etc. with these system calls. The behavior will be slightly different, however -- I'm not sure if this API supports everything we expect the SysV IPC API to support (e.g. telling the # of clients attached to a given segment). Can anyone comment on exactly what functionality we expect when dealing with the storage mechanism of the shared buffer? Any comments would be appreciated. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly