Messages in this thread | | | Date | Wed, 22 May 2002 11:40:44 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Have the 2.4 kernel memory management problems on large machines been fixed? |
| |
On Wed, 22 May 2002, Rik van Riel wrote: > > > > It's a magic x86-only system call, > > > Making the _generic_ code jump through hoops because some stupid special > > case that nobody else is interested in is bad. > > Actually, I suspect that MIPS, x86-64 and other > architectures are also interested ...
Oh, it can certainly have similar semantics on other architectures, the point really being not so much the x86'ness, but the fact that this is a separate subsystem with very limited scope.
Limiting the scope means, for example, that:
- no issues about memory coherency of shared mappings with "read/write"
mmap _has_ to be coherent for good behaviour (yeah, yeah, I know there are systems out there that aren't, but they are clearly inferior and cannot run innd with mappings etc).
But doing some kind of "file coherent big page" support is just too horrible for words.
- no mixups with "get_unmapped_page()" and friends having to be able to find aligned mappings, and more magic paths on mmap/unmap. As far as the rest of the VM, the big pages are basically just not there. Make that explicit by actually making "pmd_present()" return 0 for big pages.
- you can later, if you want, _extend_ the semantics without breaking stuff, if some future VM actually wants to be natively aware of big pages. I consider that unlikely, but hey..
Is it fairly ugly? Yes. But it gets the job done, and doing it in some special C file with little impact on the rest of the system means that we can tweak it for the hardware instead of trying to make it a "good design".
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |