Re: xeon processors

Поиск
Список
Период
Сортировка
От Manfred Spraul
Тема Re: xeon processors
Дата
Msg-id 40E44394.7020302@colorfullife.com
обсуждение исходный текст
Ответ на Re: xeon processors  (Christopher Browne <cbbrowne@acm.org>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Adding column comment to information_schema.columns
Следующее
От: Tom Lane
Дата:
Сообщение: Schedule, feature freeze, etc