Feizhou wrote: > I thought they have done away with the high memory bounce buffers? Bryan J. Smith wrote: > Correct. On x86-64, they have. Feizhou wrote: > Ok earlier you said: > "At more than 1GiB on Linux/x86, you must use a 4G+4G kernel > (this is the default) to see more than 960MiB. This causes a > signficant (10%+) performance hit. On more than 4GiB, it is > worsened as more extensive paging is used." Note I said "Linux/x86" and _not_ "Linux/x86-64". > where does the performance hit for 4G/4G on Intel (whether > ia32e or not) come from? The performance hit is for _all_ IA-32 compatible architectures running Linux/x86, because there is definitely a hit. There's a hit for the 4G+4G HIGHMEM model. And there is another, bigger one if you go 64G model (more than 4GiB user). As far as _both_ Intel IA-32 on Linux/x86 _and_ Intel IA-32e (EM64T) on Linux/x86-64, you _always_ have "bounce buffers" (c/o the Soft I/O MMU, Soft IOTLB in Linux/x86-64 on EM64T) if you are doing a transfer between two memory areas -- e.g., user memory and memory mapped I/O -- when _one_ area is above 4GiB. No way around that, and a major problem with Intel right now. x86-64 (AMD64) on Linux/x86-64 uses its I/O MMU hardware to drastically improve the performance. There were a few bugs early on, but most of them have been resolved. I'm still checking on the "hack" for a select few so-called "32-bit" Athlon MP mainboards to find out all the true capabilities of it. But I have _never_ been mistaken on the EV6 platform as 40-bit natively capable. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;->