On Thu, May 16, 2002 at 09:15:40AM +0200, Kevin D. Kissell wrote: > Is this to say that Linux cannot function unless all physical memory > on the system is mapped at all times into kernel space? I would > have thought that (a) all that really needs to be mapped is all > memory used by the kernel itself, plus that of the currently active > process (which is mapped in the 2GB kuseg), and that (b) one > could anyway manage kseg2 or 3 dynamically to provide a window > into a larger physical memory, and that this window could be > used for any functions that need to do arbitrary phys-to-phys > copies. Highmem is your dynamic 4MB window into all memory that's not low memory. KSEG2/3 are currently mostly reserved for vmalloc / ioremap and these 4MB of highmem mapping space - a usage that's certainly wasteful. As opposed to that all the permanently mapped kernel memory in Linux is called lowmem. > I'm not sure what people's definition of a "64-bit kernel" > is around here, but to me, that's a kernel which supports > 64-bit virtual addressing and 64-bit registers. It strikes > me as being rather foolish to impose the overhead of all > that on people whose only real requirement is 2G of RAM > on a 32-bit CPU. Particularly when many of the new > MIPS parts that could plausibly be connected to 2GB > RAM arrays, such as the Alchemy/AMD and MIPS 4K > parts, don't support 64-bit operation. So running away > from the problem isn't really an option. Highmem doesn't come without a price either - in particular processes doing heavy I/O will possibly as much as 40% performance penalty (numbers from Intel systems) and for sanity's sake - 64-bit is keeping people from going nuts :) A solution that will use most of KSEG2/3 for mapping more lowmemory is in the works but it turned out to be drastically more complex that originally thought so will still take a bit. Ralf
