Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Till Smejkal
On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > One advantage of VAS segments is that they can be globally queried by user > > programs > > which means that VAS segments can be shared by applications that not > > necessarily have > > to be related. If I am not mistaken, MAP_SHARED of pure in

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Till Smejkal
On Wed, 15 Mar 2017, Andy Lutomirski wrote: > On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal > <till.smej...@googlemail.com> wrote: > > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > >> > One advantage of VAS segments is that they can be globally queried by > >

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Till Smejkal
On Wed, 15 Mar 2017, Luck, Tony wrote: > On Wed, Mar 15, 2017 at 03:02:34PM -0700, Till Smejkal wrote: > > I don't agree here. VAS segments are basically in-memory files that are > > handled by > > the kernel directly without using a file system. Hence, if an applic

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Till Smejkal
On Thu, 16 Mar 2017, Thomas Gleixner wrote: > On Thu, 16 Mar 2017, Till Smejkal wrote: > > On Thu, 16 Mar 2017, Thomas Gleixner wrote: > > > Why do we need yet another mechanism to represent something which looks > > > like a file instead of simply using existing

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Till Smejkal
On Thu, 16 Mar 2017, Thomas Gleixner wrote: > Why do we need yet another mechanism to represent something which looks > like a file instead of simply using existing mechanisms and extend them? You are right. I also recognized during the discussion with Andy, Chris, Matthew, Luck, Rich and the

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-14 Thread Till Smejkal
On Tue, 14 Mar 2017, Chris Metcalf wrote: > On 3/14/2017 12:12 PM, Till Smejkal wrote: > > On Mon, 13 Mar 2017, Andy Lutomirski wrote: > > > On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal > > > <till.smej...@googlemail.com> wrote: > > > &g

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-14 Thread Till Smejkal
On Mon, 13 Mar 2017, Andy Lutomirski wrote: > On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal > <till.smej...@googlemail.com> wrote: > > On Mon, 13 Mar 2017, Andy Lutomirski wrote: > >> This sounds rather complicated. Getting TLB flushing right seems > >> tric

Re: [RFC PATCH 07/13] kernel/fork: Split and export 'mm_alloc' and 'mm_init'

2017-03-14 Thread Till Smejkal
On Tue, 14 Mar 2017, David Laight wrote: > From: Linuxppc-dev Till Smejkal > > Sent: 13 March 2017 22:14 > > The only way until now to create a new memory map was via the exported > > function 'mm_alloc'. Unfortunately, this function not only allocates a new > > memo

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-14 Thread Till Smejkal
On Mon, 13 Mar 2017, Andy Lutomirski wrote: > On Mon, Mar 13, 2017 at 3:14 PM, Till Smejkal > <till.smej...@googlemail.com> wrote: > > This patchset extends the kernel memory management subsystem with a new > > type of address spaces (called VAS) which can

[RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions

2017-03-13 Thread Till Smejkal
destroy or create a virtual segment. Via attaching a VAS segment to a first class virtual address space, the memory that is contained in the VAS segment can be accessed and changed. Signed-off-by: Till Smejkal <till.smej...@gmail.com> Signed-off-by: Marco Benatto <marco.antonio@

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-13 Thread Till Smejkal
On Tue, 14 Mar 2017, Richard Henderson wrote: > On 03/14/2017 08:14 AM, Till Smejkal wrote: > > At the current state of the development, first class virtual address spaces > > have one limitation, that we haven't been able to solve so far. The feature > > allows, that differen

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-13 Thread Till Smejkal
On Tue, 14 Mar 2017, Richard Henderson wrote: > On 03/14/2017 10:39 AM, Till Smejkal wrote: > > > Is this an indication that full virtual address spaces are useless? It > > > would seem like if you only use virtual address segments then you avoid > > > all > &

[RFC PATCH 13/13] fs/proc: Add procfs support for first class virtual address spaces

2017-03-13 Thread Till Smejkal
of the underlying VAS. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- fs/proc/base.c | 528 + fs/proc/inode.c| 1 + fs/proc/internal.h | 1 + mm/Kconfig | 9 + 4 files changed, 539 insertions(+) diff --git a/f

[RFC PATCH 10/13] mm: Introduce first class virtual address spaces

2017-03-13 Thread Till Smejkal
at the same time if the underlying memory is only readable. This mechanism allows sharing of whole address spaces between multiple processes that can both execute in them using the contained memory. Signed-off-by: Till Smejkal <till.smej...@gmail.com> Signed-off-by: Marco Benatto <marc

[RFC PATCH 09/13] mm/memory: Add function to one-to-one duplicate page ranges

2017-03-13 Thread Till Smejkal
-by: Till Smejkal <till.smej...@gmail.com> --- include/linux/huge_mm.h | 6 + include/linux/hugetlb.h | 5 + include/linux/mm.h | 2 + mm/huge_memory.c| 65 +++ mm/hugetlb.c| 205 +++-- mm/memory.c

[RFC PATCH 04/13] mm: Add mm_struct argument to 'get_unmapped_area' and 'vm_unmapped_area'

2017-03-13 Thread Till Smejkal
with its dependents have to take the memory map that they should work on as additional argument. Simply using the one of the current task, as these functions did before, is not correct anymore and leads to incorrect results. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- arch/alpha/

[RFC PATCH 06/13] mm/mmap: Export 'vma_link' and 'find_vma_links' to mm subsystem

2017-03-13 Thread Till Smejkal
Make the functions 'vma_link' and 'find_vma_links' accessible to other source files in the mm/ source directory of the kernel so that other files in that directory can also perform low level changes to mm_struct data structures. Signed-off-by: Till Smejkal <till.smej...@gmail.com> -

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

2017-03-13 Thread Till Smejkal
Hi Greg, First of all thanks for your reply. On Tue, 14 Mar 2017, Greg Kroah-Hartman wrote: > On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote: > > There's no way with that many cc: lists and people that this is really > making it through very many people's filters

[RFC PATCH 08/13] kernel/fork: Define explicitly which mm_struct to duplicate during fork

2017-03-13 Thread Till Smejkal
ain deciding which mm_struct to use. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- kernel/fork.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 9209f6d5d7c0..d3087d870855 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @

Re: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions

2017-03-13 Thread Till Smejkal
Hi Matthew, On Mon, 13 Mar 2017, Matthew Wilcox wrote: > On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote: > > +/** > > + * Create a new VAS segment. > > + * > > + * @param[in] name:The name of the new VAS segment. > > + * @param[in]

[RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-13 Thread Till Smejkal
during an internship at Hewlett Packard Enterprise. [1] http://impact.crhc.illinois.edu/shared/Papers/ASPLOS16-SpaceJMP.pdf Till Smejkal (13): mm: Add mm_struct argument to 'mmap_region' mm: Add mm_struct argument to 'do_mmap' and 'do_mmap_pgoff' mm: Rename 'unmap_region' and add mm_struct

[RFC PATCH 07/13] kernel/fork: Split and export 'mm_alloc' and 'mm_init'

2017-03-13 Thread Till Smejkal
' and 'mm_set_task' are also exported, so that they can be used in all files in the source tree. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- arch/arm/mach-rpc/ecard.c | 2 +- fs/exec.c | 2 +- include/linux/sched.h | 7 +- kernel/fork.c

[RFC PATCH 12/13] mm/vas: Add lazy-attach support for first class virtual address spaces

2017-03-13 Thread Till Smejkal
inside the first class virtual address space. The only memory region which is always duplicated during the attach-operation is the code memory section, because this memory region is always necessary for execution and saves us one page fault later during the process execution. Signed-off-by: Till

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

2017-03-13 Thread Till Smejkal
Hi Vineet, On Mon, 13 Mar 2017, Vineet Gupta wrote: > I've not looked at the patches closely (or read the references paper fully > yet), > but at first glance it seems on ARC architecture, we can can potentially > use/leverage this mechanism to implement the shared TLB entries. Before anyone >

[RFC PATCH 05/13] mm: Add mm_struct argument to 'mm_populate' and '__mm_populate'

2017-03-13 Thread Till Smejkal
need to be able to operate on other memory maps than just the one of the current task. Accordingly, it is now possible to specify explicitly which memory map these functions should use via an additional argument. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- arch/x86/mm/mpx.c

[RFC PATCH 01/13] mm: Add mm_struct argument to 'mmap_region'

2017-03-13 Thread Till Smejkal
maps than only the current task ones. By adding it as argument we can now explicitly define which memory map to use. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- arch/mips/kernel/vdso.c | 2 +- arch/tile/mm/elf.c | 2 +- include/linux/mm.h | 5 +++-- mm/

[RFC PATCH 03/13] mm: Rename 'unmap_region' and add mm_struct argument

2017-03-13 Thread Till Smejkal
a new argument to the function so that one can define explicitly which memory map should be used. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- include/linux/mm.h | 4 mm/mmap.c | 14 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/include/

[RFC PATCH 02/13] mm: Add mm_struct argument to 'do_mmap' and 'do_mmap_pgoff'

2017-03-13 Thread Till Smejkal
for other memory maps than just the one of the current process. Hence, explicitly define during the function call which memory map to use. Signed-off-by: Till Smejkal <till.smej...@gmail.com> --- arch/x86/mm/mpx.c | 4 ++-- fs/aio.c | 4 ++-- include/linux/mm.h | 11 ++- ipc