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
- 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/