On Wed, Oct 24 2007 at 18:35 +0200, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > On Wed, Oct 24, 2007 at 04:41:16PM +0200, Boaz Harrosh wrote: >> I thought that for 4GB of memory the CONFIG_HIGHMEM4G=y CONFIG_HIGHMEM64G is >> not set >> would be enough. >> >> From looking in source code the CONFIG_HIGHMEM64G is broken in many respects, >> in my opinion. It's really a 64-bit with 32-bit quirks enabled. Does it even >> run on None 64-bit machines? Not many! >> >> You have a magnificent 64-bit Machine, why? > > CONFIG_HIGHMEM4G means 4GB address space. Since PCI and BIOS use some > of the first 4GB address space, a machine with 4GB of actual RAM must > map some of that RAM above the 4GB address space, so you access it all > you need to enable PAE (address space extensions intel invented to give > 36bit addressing on 32bit machines), which lets the OS map memory above > 4GB (up to 64GB), to let applications use it. Applications are still > limited to a 32bit address space. 64bit machines of course just use all > memory directly without any silly extensions. > > The common intel BIOS bug relating to configuring the MTRR and such for > caching of memory makes the top portion of memory uncached and hence > very slow, which means any code placed in the top part of memory gets > slow. The kernel likes to place itself at the top of memory which means > the kernel gets slow and hence the whole system gets slow. Holefully > intel will learn to make proper BIOSes real soon so that people with > intel boards can stop having such slow machines when they have lots of > ram. > > -- > Len Sorensen
So one thing I don't understand is the difference between CONFIG_HIGHMEM4G and regular 32-bit. I always thought that 32 bit means 4GB address space and that the HIGHMEM4G is using your above trick but with 32-bit dma_addr_t since there is only actual 4GB of real memory and the rest is mapping tricks. But I guess I was wrong. The other point I was making is why use 36 bit trickery when you have a machine that is capable of the full 64-bit, and runs much faster at that? Just a waste of a good machine, wont you say? Perhaps we learn to use x86_64 ARCHs before Intel fixes their BIOS, and they where right all along? Boaz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
