Kevin D. Kissell wrote: > Jun Sun wrote: > >>Daniel Jacobowitz wrote: >> >> >>>On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: >>> >>> >>>>So... I'm looking at porting Linux to a system with 1.5GiB of RAM. >>>>That kinda blows the 32-bit MIPS port option right out of the water... >>>> >>>> >>>Not unless you count bits differently than I do... 32-bit is 4 GiB. Is >>>there any reason MIPS has special problems in this area? >>> >>> >> >>MIPS has lower 2GB fixed for user space. Then you have kseg0, .5GB for cached >>physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping of the same area. >> You can map another 1GB of RAM into kseg2/3, but you will then have no space >>left for IO. >> >>So you really can't do 1.5GB on 32 bit kernel. >> > > 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. > You are right - my above statement is a grossly simplified way of saying "You can't really have 1.5GB system RAM accessible to kernel at the same time on a 32bit MIPS kernel". There is nothing preventing you from having more physical RAM and use dynamically by using HIGHMEM support. BTW, I have been under the impression that demand for larger system RAM mainly comes from large router/switches to store routing table. Does anybody know on such systems whether the routing code runs in kernel or user space and whether it requires all the memory space accessible at the same time or can live with dynamically managed memory space? Jun
