On 11/26/05, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > No. So as to not have to switch pagetables (and therefore flush the TLB, > the on-CPU pagetable cache, which is a very costly operation) upon each > entry to and exit from the kernel, kernel and user address space share > that same 4GB. Userspace normally gets 3GB of it -- you supposedly > bought the machine to run applications and not so much a kernel -- > leaving 1GB for the kernel. Subtract 128M of addressspace which is > reserved for things like vmalloc() and ioremap() (and high memory > mappings...) and you're at that familiar 896M. Hi, Thank you very much. Your answer is well appreciated. I see the point now. Is it then correct to summarize: Kernel and userspace virtual memory is split to 1gb/3gb regions to share virtual memory space and avoid tlb flushes upon user/kernel mode switches, whereas the fact that kernel has 896mb logical space is because mapping the whole address space requires lots of pte space. I guess you could still have a 1gb/3gb split, but at the same time, be able to keep all the memory mapped in page tables, whether or not it belongs to 1gb kernel or 3gb user space. Is this correct? > the lower part (896M) of memory is still > permanently mapped as was always the case, and you map memory above that > into kernel space when required, and unmap it when no longer needed. > Which works. It's certainly not the cleanest approach if you're the kind > who likes neat schematic drawings of algorithms (I am. Oh am I ever) but > it works. It's also not very fast, but when a TLB flush is the > alternative it doesn't easily get worse. When does it get worse? Perhaps if you attempt to map a large unmapped area, it would take more than a single tlb flush? > As to future, certainly after x86-64 (or another > 64-bit arch) truly obsoletes x86 I personally believe it might be worth > it to allways use 4G/4G (or at least for machines with more than 896M), > say "sorry, guys, we don't support more than 4G on x86 anymore", and rip > out the highmem code. Would certainly make for an easier maintainable > VM, and it will probably need to be maintained for a long time still for > embedded use. Do you think high-memory is less maintainable because you wouldn't be sure whether any page or address you access in the kernel may or may not be a logical address, i.e. mapped at that moment, and you would have to cope with this? > Another thing, which is significantly easier to do: adjust the split > down somewhat. I've been told it's against some SysV ABI to go beneath > 3G for userspace but chances are good you won't care too much. This was another issue I had in mind. When you adjust the virtual memory area for applications, how does it affect applications already compiled and linked for a particular address? You could surely mmap files or use relocatable shared librarys, but perhaps need to recompile non-relocatable executables? For > machines with 1G to have to cope with highmem just to get that last 128M > supported is fairly icky. If in include/asm/page.h you adjust the > __PAGE_OFFSET define(s) down a bit, that should be all you need. From 3G > (0xc0000000) to 0xb8000000 (3G-128M) or 0xb0000000 for good measure. A > patch which does this for you also lives in the -ck tree, available at: > > http://members.optusnet.com.au/ckolivas/kernel/ Finally for such a 1gb machine that you mapped the total physical memory as logical kernel addresses, would a vmalloc call act like a kmalloc call, in the sense that it wouldn't need any pagetable reorganisation but return mapped addresses immediately? > Hope this was useful... > > Rene. > Yes it was very useful. Thank you, Bahadir -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
