Skip site navigation (1) Skip section navigation (2)

Re: xeon processors

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: xeon processors
Date: 2004-07-01 17:02:12
Message-ID: 40E44394.7020302@colorfullife.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Christopher Browne wrote:

>The "fix" for this problem is to rewrite all of your applications so
>that they become conscious of which bits of memory they're using so
>they can tune their own behaviour.  This, of course, requires
>discarding useful notions such as "virtual memory" that are _assumed_
>by most modern operating systems.
>
>  
>
This is misleading: PAE means that a 32-bit cpu can have more that 4 GB 
physical memory. Each process can map at most 4 (in reality: ~2) GB memory.
Many databases manage their own, huge buffer pool and read/write the 
database tables with O_DIRECT. These apps must support buffer pools > 2 
GB, which requires some work. Linux and Solaris contain a special 
syscall that helps Oracle to manage it's buffer pool for such setups 
(remap_page_rage()).
OTHO postgres has a small user space buffer pool, the majority of the 
file buffers are handled by OS. Thus no changes are required inside 
postgres for PAE, all it needs is an OS that support PAE for the buffer 
pool.

Regarding hyperthreading: I'm aware of two changes:
- busy loops must contain PAUSE instructions. Postgres does that.
- virtual aliases should be avoided: If two processes access memory at 
the same virtual address, then this can cause cache collisions and then 
misses. I think this is handled by the C library by randomizing the 
return addresses of malloc() and Intel mitigated the issue by improving 
the cache.

--
    Manfred

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-07-01 17:02:27
Subject: Schedule, feature freeze, etc
Previous:From: jearlDate: 2004-07-01 16:38:02
Subject: Re: Adding column comment to information_schema.columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group