On Wed, Mar 07, 2007 at 09:53:23AM +0100, Ingo Molnar wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > btw., if we decide that nonlinear isnt worth the continuing > > > maintainance pain, we could internally implement/emulate > > > sys_remap_file_pages() via a call to mremap() and essentially > > > deprecate it, without breaking the ABI - and remove all the > > > nonlinear code. (This would split fremap areas into separate vmas) > > > > > > > I'm rather regretting having merged it - I don't think it has been > > used for much. > > > > Paolo's UML speedup patches might use nonlinear though. > > yes, i wrote the first, prototype version of that for UML, it needs an > extended version of the syscall, sys_remap_file_pages_prot(): > > > http://redhat.com/~mingo/remap-file-pages-patches/remap-file-pages-prot-2.6.4-rc1-mm1-A1 > > i also wrote an x86 hypervisor kind of thing for UML, called > 'sys_vcpu()', which allows UML to execute guest user-mode in a box, > which also relies on sys_remap_file_pages_prot(): > > http://redhat.com/~mingo/remap-file-pages-patches/vcpu-2.6.4-rc2-mm1-A2 > > which reduced the UML guest syscall overhead from 30 usecs to 4 usecs > (with native syscalls taking 2 usecs, on the box i tested, years ago). > > So it certainly looked useful to me - but wasnt really picked up widely. > > We'll always have the option to get rid of it (and hence completely > reverse the decision to merge it) without breaking the ABI, by emulating > the API via mremap(). That eliminates the UML speedup though. So no need > to feel sorry about having merged it, we can easily revisit that > years-old 'do we want it' decision, without any ABI worries.
Depending on whether anyone wants it, and what features they want, we could emulate the old syscall, and make a new restricted one which is much less intrusive. For example, if we can operate only on MAP_ANONYMOUS memory and specify that nonlinear mappings effectively mlock the pages, then we can get rid of all the objrmap and unmap_mapping_range handling, forget about the writeout and msync problems... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
