Ralf, On Wed, 26 Jun 2013, Leonid Yegoshin wrote: > > > EVA has actually INCREASE in user address space - I right now run system > > > with 2GB phys memory and 3GB of user virtual memory address space. Work in > > > progress is to verify that GLIBC accepts addresses above 2GB. > > I took the 0x40000000 for a KSEG0-equivalent because you previously > > mentioned the value of 0x80000000. > > I wrote about kernel address layout. With EVA a user address layout is a > different beast. > In EVA, user may have access, say [0x00000000 - 0xBFFFFFFF] through TLB and > kernel may have access, say [0x00000000 - 0xDFFFFFFF] unmapped. But segment > shifts are applied to each KSEG. > > > > Yes, it is all about increasing phys and user memory and avoiding 64bits. > > > Many solutions dont justify 64bit chip (chip space increase, performance > > > degradation and increase in DMA addresses for devices). > > Fair enough - but in the end the increasing size of metadata and pagetables > > which has to reside in lowmem will become the next bottleneck and highmem > > I/O performance has never been great, is on most kernel developers shit list > > and performance optimizations for highmem are getting killed whenever they > > are getting into the way. > > EVA doesn't use HIGHMEM. Kernel has a direct access to all memory in, say 3GB > (3.5GB?). > Malta model gives only 2GB because of PCI bridge loop problem. To complete the image, there is a set of new memory access instructions added (including but not limited to CACHE) that in the kernel mode separates accesses to the user space from accesses to the kernel space, i.e. the same virtual address can map differently depending on which instruction set it is used with. I encourage you to have at least a skim over the most recent set of MIPS architecture manuals publicly available where it all is documented. Maciej
