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
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
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
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
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
> >
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
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
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
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
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
>
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
> &
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
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
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
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
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
@
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]
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>
-
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
-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
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/
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@
' 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
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
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/
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/
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
27 matches
Mail list logo
