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
