Re: xeon processors
От | Doug McNaught |
---|---|
Тема | Re: xeon processors |
Дата | |
Msg-id | 87isd7zz32.fsf@asmodeus.mcnaught.org обсуждение исходный текст |
Ответ на | Re: xeon processors (Christopher Browne <cbbrowne@acm.org>) |
Список | pgsql-hackers |
Christopher Browne <cbbrowne@acm.org> writes: > Centuries ago, Nostradamus foresaw when systemguards@yahoo.com (Jaime Casanova) would write: >> Can anyone tell me if postgresql has problems with xeon processors? >> >> If so, there is any fix or project of fix it? > > Well, there's a known issue that IA-32 systems with more than 4GB of > memory use an extension known as "PAE" to bank-switch between the > banks of memory. AIUI, it's not really "bank switching" in the old 8-bit sense. Rather, there is a big linear 36-bit physical address space, and the processor's page tables have been extended so they can point to any page in this space. Any one process still sees a 4GB (32-bit) address space since that's how big the registers are. > Any time you switch banks, there's a fair little bit of work to be > done. That includes multitasking systems that need to context switch > a few thousand times per second. I don't think this is any more overhead than a "normal" context switch--cache misses, TLB flush etc. > 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 only if you need to address more than 32-bits worth of address in a single process, which is not always the case on server-class systems (on scientific/numerical workloads, it's often a big win). In which case you are certainly right: > The fix is to buy hardware that hasn't been hacked up so badly. 64-bit systems get cheaper all the time... :) -Doug
В списке pgsql-hackers по дате отправления: