All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: kirill@shutemov.name, linux-kernel@vger.kernel.org,
	kernel-team@android.com, minchan@kernel.org, pantin@google.com,
	hughd@google.com, lokeshgidra@google.com, dancol@google.com,
	mhocko@kernel.org, akpm@linux-foundation.org,
	aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de,
	catalin.marinas@arm.com, chris@zankel.net,
	dave.hansen@linux.intel.com, elfring@users.sourceforge.net,
	fenghua.yu@intel.com, geert@linux-m68k.org, gxt@pku.edu.cn,
	deller@gmx.de, mingo@redhat.com, jejb@parisc-linux.org,
	jdike@addtoit.com, jonas@southpole.se, Julia.Lawall@lip6.fr,
	kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu,
	lftan@altera.com, linux-alpha@vger.kernel.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.orgl
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Sat, 13 Oct 2018 01:35:40 +0000	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: kirill@shutemov.name, linux-kernel@vger.kernel.org,
	kernel-team@android.com, minchan@kernel.org, pantin@google.com,
	hughd@google.com, lokeshgidra@google.com, dancol@google.com,
	mhocko@kernel.org, akpm@linux-foundation.org,
	aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de,
	catalin.marinas@arm.com, chris@zankel.net,
	dave.hansen@linux.intel.com, elfring@users.sourceforge.net,
	fenghua.yu@intel.com, geert@linux-m68k.org, gxt@pku.edu.cn,
	deller@gmx.de, mingo@redhat.com, jejb@parisc-linux.org,
	jdike@addtoit.com, jonas@southpole.se, Julia.Lawall@lip6.fr,
	kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu,
	lftan@altera.com, linux-alpha@vger.kernel.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.org, l
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: kirill@shutemov.name, linux-kernel@vger.kernel.org,
	kernel-team@android.com, minchan@kernel.org, pantin@google.com,
	hughd@google.com, lokeshgidra@google.com, dancol@google.com,
	mhocko@kernel.org, akpm@linux-foundation.org,
	aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de,
	catalin.marinas@arm.com, chris@zankel.net,
	dave.hansen@linux.intel.com, elfring@users.sourceforge.net,
	fenghua.yu@intel.com, geert@linux-m68k.org, gxt@pku.edu.cn,
	deller@gmx.de, mingo@redhat.com, jejb@parisc-linux.org,
	jdike@addtoit.com, jonas@southpole.se, Julia.Lawall@lip6.fr,
	kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu,
	lftan@altera.com, linux-alpha@vger.kernel.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.org,
	linux-mm@kvack.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org,
	linux-xtensa@linux-xtensa.org, jcmvbkbc@gmail.com,
	nios2-dev@lists.rocketboards.org, peterz@infradead.org,
	richard@nod.at
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel


WARNING: multiple messages have this Message-ID (diff)
From: joel@joelfernandes.org (Joel Fernandes)
To: linux-riscv@lists.infradead.org
Subject: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
	linux-riscv@lists.infradead.org, elfring@users.sourceforge.net,
	jonas@southpole.se, linux-s390@vger.kernel.org,
	dancol@google.com, linux-xtensa@linux-xtensa.org,
	linux-hexagon@vger.kernel.org, deller@gmx.de, hughd@google.com,
	jejb@parisc-linux.org, kasan-dev@googlegroups.com,
	kvmarm@lists.cs.columbia.edu, mingo@redhat.com,
	geert@linux-m68k.org, aryabinin@virtuozzo.com,
	linux-snps-arc@lists.infradead.org, kernel-team@android.com,
	fenghua.yu@intel.com, jdike@addtoit.com,
	linux-um@lists.infradead.org, Julia.Lawall@lip6.fr,
	linux-m68k@lists.linux-m68k.org, bp@alien8.de, luto@kernel.org,
	nios2-dev@lists.rocketboards.org, kirill@shutemov.name,
	gxt@pku.edu.cn, chris@zankel.net, richard@nod.at,
	linux-parisc@vger.kernel.org, pantin@google.com,
	jcmvbkbc@gmail.com, linux-kernel@vger.kernel.org,
	minchan@kernel.org, linux-alpha@vger.kernel.org,
	lftan@altera.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
Message-ID: <20181013013540.zhw7pjSjxg_Yzfa-wrqun3Ju9Sz-LXVTIifv_9oNCEA@z> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
	linux-riscv@lists.infradead.org, elfring@users.sourceforge.net,
	jonas@southpole.se, linux-s390@vger.kernel.org,
	dancol@google.com, linux-xtensa@linux-xtensa.org,
	linux-hexagon@vger.kernel.org, deller@gmx.de, hughd@google.com,
	jejb@parisc-linux.org, kasan-dev@googlegroups.com,
	kvmarm@lists.cs.columbia.edu, mingo@redhat.com,
	geert@linux-m68k.org, aryabinin@virtuozzo.com,
	linux-snps-arc@lists.infradead.org, kernel-team@android.com,
	fenghua.yu@intel.com, jdike@addtoit.com,
	linux-um@lists.infradead.org, Julia.Lawall@lip6.fr,
	linux-m68k@lists.linux-m68k.org, bp@alien8.de, luto@kernel.org,
	nios2-dev@lists.rocketboards.org, kirill@shutemov.name,
	gxt@pku.edu.cn, chris@zankel.net, richard@nod.at,
	linux-parisc@vger.kernel.org, pantin@google.com,
	jcmvbkbc@gmail.com, linux-kernel@vger.kernel.org,
	minchan@kernel.org, linux-alpha@vger.kernel.org,
	lftan@altera.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel


WARNING: multiple messages have this Message-ID (diff)
From: joel@joelfernandes.org (Joel Fernandes)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018@11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel at joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: kirill@shutemov.name, linux-kernel@vger.kernel.org,
	kernel-team@android.com, minchan@kernel.org, pantin@google.com,
	hughd@google.com, lokeshgidra@google.com, dancol@google.com,
	mhocko@kernel.org, akpm@linux-foundation.org,
	aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de,
	catalin.marinas@arm.com, chris@zankel.net,
	dave.hansen@linux.intel.com, elfring@users.sourceforge.net,
	fenghua.yu@intel.com, geert@linux-m68k.org, gxt@pku.edu.cn,
	deller@gmx.de, mingo@redhat.com, jejb@parisc-linux.org,
	jdike@addtoit.com, jonas@southpole.se, Julia.Lawall@lip6.fr,
	kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu,
	lftan@altera.com, linux-alpha@vger.kernel.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.orgl
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space?  We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
> 
> Sparc makes sure that shared mapping have consistent colors.  Therefore
> all that's left are private mappings and those will be initialized by
> block stores to clear the page out or similar.
> 
> Also, when creating new mappings, we flush the D-cache when necessary
> in update_mmu_cache().
> 
> We also maintain a bit in the page struct to track when a page which
> was potentially written to on one cpu ends up mapped into another
> address space and flush as necessary.
> 
> The cache is write-through, which simplifies the preconditions we have
> to maintain.

Makes sense, thanks. For the moment I sent patches to enable this on arm64
and x86. We can enable it on sparc as well at a later time as it sounds it
could be a safe optimization to apply to that architecture as well.

thanks,

 - Joel

  reply	other threads:[~2018-10-13  1:35 UTC|newest]

Thread overview: 317+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12  1:37 [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions Joel Fernandes (Google)
2018-10-12  1:37 ` [OpenRISC] " Joel Fernandes
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` Joel Fernandes (Google)
2018-10-12  1:37 ` [PATCH v2 2/2] mm: speed up mremap by 500x on large regions Joel Fernandes (Google)
2018-10-12  1:37   ` [OpenRISC] " Joel Fernandes
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  1:37   ` Joel Fernandes (Google)
2018-10-12  6:40   ` Anton Ivanov
2018-10-12 11:30   ` Kirill A. Shutemov
2018-10-12 11:30     ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:36     ` Kirill A. Shutemov
2018-10-12 11:36       ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 12:50     ` Joel Fernandes
2018-10-12 12:50       ` [OpenRISC] " Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 13:19       ` Kirill A. Shutemov
2018-10-12 13:19         ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 16:57         ` Joel Fernandes
2018-10-12 16:57           ` [OpenRISC] " Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 21:33           ` Kirill A. Shutemov
2018-10-12 21:33             ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 18:18       ` David Miller
2018-10-12 18:18         ` [OpenRISC] " David Miller
2018-10-12 18:18         ` David Miller
2018-10-12 18:18         ` David Miller
2018-10-12 18:18         ` David Miller
2018-10-12 18:18         ` David Miller
2018-10-12 18:18         ` David Miller
2018-10-12 18:18         ` David Miller
2018-10-13  1:35         ` Joel Fernandes [this message]
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:39           ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:44             ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:54               ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  2:10                 ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:25                   ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13 17:50                     ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-12 18:02     ` David Miller
2018-10-12 18:02       ` [OpenRISC] " David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 14:09   ` Anton Ivanov
2018-10-12 14:09     ` [OpenRISC] " Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:37     ` Kirill A. Shutemov
2018-10-12 14:37       ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:48       ` Anton Ivanov
2018-10-12 14:48         ` [OpenRISC] " Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 16:42         ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` [OpenRISC] " Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:50           ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` [OpenRISC] " Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:58             ` Anton Ivanov
2018-10-12 16:58               ` [OpenRISC] " Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 17:06               ` Joel Fernandes
2018-10-12 17:06                 ` [OpenRISC] " Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 21:40           ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-13  6:10             ` Anton Ivanov
2018-10-13  6:10               ` [OpenRISC] " Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-15  7:10   ` Christian Borntraeger
2018-10-15  7:10     ` [OpenRISC] " Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  8:18     ` Martin Schwidefsky
2018-10-15  8:18       ` [OpenRISC] " Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-16  2:08       ` Joel Fernandes
2018-10-16  2:08         ` [OpenRISC] " Joel Fernandes
2018-10-16  2:08         ` Joel Fernandes
2018-10-16  2:08         ` Joel Fernandes
2018-10-16  2:08         ` Joel Fernandes
2018-10-16  2:08         ` Joel Fernandes
2018-10-16  2:08         ` Joel Fernandes
2018-10-16  2:08         ` Joel Fernandes
2018-10-12 11:09 ` [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions Kirill A. Shutemov
2018-10-12 11:09   ` [OpenRISC] " Kirill A. Shutemov
2018-10-12 11:09   ` Kirill A. Shutemov
2018-10-12 11:09   ` Kirill A. Shutemov
2018-10-12 11:09   ` Kirill A. Shutemov
2018-10-12 11:09   ` Kirill A. Shutemov
2018-10-12 11:09   ` Kirill A. Shutemov
2018-10-12 11:09   ` Kirill A. Shutemov
2018-10-12 16:37   ` Joel Fernandes
2018-10-12 16:37     ` [OpenRISC] " Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 13:56 ` Anton Ivanov
2018-10-12 13:56   ` [OpenRISC] " Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 16:34   ` Joel Fernandes
2018-10-12 16:34     ` [OpenRISC] " Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:38     ` Julia Lawall
2018-10-12 16:38       ` [OpenRISC] " Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:46       ` Joel Fernandes
2018-10-12 16:46         ` [OpenRISC] " Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 18:51 ` SF Markus Elfring
2018-10-12 18:51   ` [OpenRISC] " SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 19:42   ` Joel Fernandes
2018-10-12 19:42     ` [OpenRISC] " Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-13  9:22     ` SF Markus Elfring
2018-10-13  9:22       ` [OpenRISC] " SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring
2018-10-13  9:22       ` SF Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181013013540.GA207108@joelaf.mtv.corp.google.com \
    --to=joel@joelfernandes.org \
    --cc=Julia.Lawall@lip6.fr \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chris@zankel.net \
    --cc=dancol@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=elfring@users.sourceforge.net \
    --cc=fenghua.yu@intel.com \
    --cc=geert@linux-m68k.org \
    --cc=gxt@pku.edu.cn \
    --cc=hughd@google.com \
    --cc=jdike@addtoit.com \
    --cc=jejb@parisc-linux.org \
    --cc=jonas@southpole.se \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel-team@android.com \
    --cc=kirill@shutemov.name \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=lftan@altera.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@linux-mips.orgl \
    --cc=lokeshgidra@google.com \
    --cc=luto@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pantin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.