[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070307092821.GB8609@wotan.suse.de>
Date: Wed, 7 Mar 2007 10:28:21 +0100
From: Nick Piggin <npiggin@...e.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linux Memory Management <linux-mm@...ck.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paolo 'Blaisorblade' Giarrusso <blaisorblade@...oo.it>
Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Wed, Mar 07, 2007 at 09:53:23AM +0100, Ingo Molnar wrote:
>
> * Andrew Morton <akpm@...ux-foundation.org> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists