From: Will Deacon <will.deacon@arm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-mips@linux-mips.org, Rich Felker <dalias@libc.org>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Balbir Singh <bsingharora@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
elfring@users.sourceforge.net, Jonas Bonn <jonas@southpole.se>,
kvmarm@lists.cs.columbia.edu, dancol@google.com,
Yoshinori Sato <ysato@users.sourceforge.jp>,
linux-xtensa@linux-xtensa.org, linux-hexagon@vger.kernel.org,
Helge Deller <deller@gmx.de>,
"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
<x86@kernel.org>,
hughd@google.com, "James E.J. Bottomley" <jejb@parisc-linux.org>,
kasan-dev@googlegroups.com, anton.ivanov@kot-begemot.co.uk,
Ingo Molnar <mingo@redhat.com>,
Geer
Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
Balbir Singh <bsingharora@gmail.com>,
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,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Andy Lutomirski <luto@kernel.org>,
anton.ivanov@kot-begemot.co.uk, Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Chris Zankel <chris@zankel.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
"David S. Miller" <davem@davemloft.net>,
elfring@users.sourceforge.net, Fenghua Yu <fenghua.yu@intel.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guan Xuetao <gxt@pku.edu.cn>, Helge Deller <deller@gmx.de>,
Ingo Molnar <mingo@redhat.com>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Jeff Dike <jdike@addtoit.com>, Jonas Bonn <jonas@southpole.se>,
Julia Lawall <Julia.Lawall@lip6.fr>,
kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu,
Ley Foon Tan <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,
Max Filippov <jcmvbkbc@gmail.com>,
nios2-dev@lists.rocketboards.org,
Peter Zijlstra <peterz@infradead.org>,
Richard Weinberger <richard@nod.at>,
Rich Felker <dalias@libc.org>, Sam Creasey <sammy@sammy.net>,
sparclinux@vger.kernel.org, Stafford Horne <shorne@gmail.com>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Luck <tony.luck@intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-riscv@lists.infradead.org
Subject: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-mips@linux-mips.org, Rich Felker <dalias@libc.org>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Balbir Singh <bsingharora@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
elfring@users.sourceforge.net, Jonas Bonn <jonas@southpole.se>,
kvmarm@lists.cs.columbia.edu, dancol@google.com,
Yoshinori Sato <ysato@users.sourceforge.jp>,
linux-xtensa@linux-xtensa.org, linux-hexagon@vger.kernel.org,
Helge Deller <deller@gmx.de>,
"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
<x86@kernel.org>,
hughd@google.com, "James E.J. Bottomley" <jejb@parisc-linux.org>,
kasan-dev@googlegroups.com, anton.ivanov@kot-begemot.co.uk,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
linux-snps-arc@lists.infradead.org, kernel-team@android.com,
Sam Creasey <sammy@sammy.net>, Fenghua Yu <fenghua.yu@intel.com>,
linux-s390@vger.kernel.org, Jeff Dike <jdike@addtoit.com>,
linux-um@lists.infradead.org,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Julia Lawall <Julia.Lawall@lip6.fr>,
linux-m68k@lists.linux-m68k.org, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
nios2-dev@lists.rocketboards.org,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Stafford Horne <shorne@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
Chris Zankel <chris@zankel.net>, Tony Luck <tony.luck@intel.com>,
Richard Weinberger <richard@nod.at>,
linux-parisc@vger.kernel.org, pantin@google.com,
Max Filippov <jcmvbkbc@gmail.com>,
linux-kernel@vger.kernel.org, minchan@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
linux-alpha@vger.kernel.org, Ley Foon Tan <lftan@altera.com>,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
Message-ID: <20181029102840.Q9kj5gdjLqiBotU7LLmmO9TP-tl9Jxk404iv0fEkZec@z> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
_______________________________________________
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: Will Deacon <will.deacon@arm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-mips@linux-mips.org, Rich Felker <dalias@libc.org>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
elfring@users.sourceforge.net, Jonas Bonn <jonas@southpole.se>,
kvmarm@lists.cs.columbia.edu, dancol@google.com,
Yoshinori Sato <ysato@users.sourceforge.jp>,
linux-xtensa@linux-xtensa.org, linux-hexagon@vger.kernel.org,
Helge Deller <deller@gmx.de>,
"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
<x86@kernel.org>,
hughd@google.com, "James E.J. Bottomley" <jejb@parisc-linux.org>,
kasan-dev@googlegroups.com, anton.ivanov@kot-begemot.co.uk,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
linux-snps-arc@lists.infradead.org, kernel-team@android.com,
Sam Creasey <sammy@sammy.net>, Fenghua Yu <fenghua.yu@intel.com>,
linux-s390@vger.kernel.org, Jeff Dike <jdike@addtoit.com>,
linux-um@lists.infradead.org,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Julia Lawall <Julia.Lawall@lip6.fr>,
linux-m68k@lists.linux-m68k.org, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
nios2-dev@lists.rocketboards.org,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Stafford Horne <shorne@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
Chris Zankel <chris@zankel.net>, Tony Luck <tony.luck@intel.com>,
Richard Weinberger <richard@nod.at>,
linux-parisc@vger.kernel.org, pantin@google.com,
Max Filippov <jcmvbkbc@gmail.com>,
linux-kernel@vger.kernel.org, minchan@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
linux-alpha@vger.kernel.org, Ley Foon Tan <lftan@altera.com>,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018@02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-mips@linux-mips.org, Rich Felker <dalias@libc.org>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Balbir Singh <bsingharora@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
elfring@users.sourceforge.net, Jonas Bonn <jonas@southpole.se>,
kvmarm@lists.cs.columbia.edu, dancol@google.com,
Yoshinori Sato <ysato@users.sourceforge.jp>,
linux-xtensa@linux-xtensa.org, linux-hexagon@vger.kernel.org,
Helge Deller <deller@gmx.de>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>,
hughd@google.com, "James E.J. Bottomley" <jejb@parisc-linux.org>,
kasan-dev@googlegroups.com, anton.ivanov@kot-begemot.co.uk,
Ingo Molnar <mingo@redhat.com>,
Geer
Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 10:28:40 +0000 [thread overview]
Message-ID: <20181029102840.GC13965@arm.com> (raw)
In-Reply-To: <20181026211148.GA140716@joelaf.mtv.corp.google.com>
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote:
> My thinking is to take it slow and get the patch in in its current state,
> since it improves x86. Then as a next step, look into why the arm64 tlb
> flushes are that expensive and look into optimizing that. On arm64 I am
> testing on a 4.9 kernel so I'm wondering there are any optimizations since
> 4.9 that can help speed it up there. After that, if all else fails about
> speeding up arm64, then I look into developing the cleanest possible solution
> where we can keep the lock held for longer and flush lesser.
We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather
code this merge window, so please do have another look at -rc1!
Will
next prev parent reply other threads:[~2018-10-29 10:28 UTC|newest]
Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-13 1:31 [PATCH 0/4] Add support for fast mremap Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` [PATCH 1/4] treewide: remove unused address argument from pte_alloc functions (v2) Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-24 8:37 ` Peter Zijlstra
2018-10-25 2:21 ` Joel Fernandes
2018-10-25 2:21 ` Joel Fernandes
2018-10-25 2:21 ` Joel Fernandes
2018-10-25 2:21 ` Joel Fernandes
2018-10-25 2:21 ` Joel Fernandes
2018-10-25 2:21 ` Joel Fernandes
2018-10-25 2:21 ` Joel Fernandes
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-26 8:52 ` Peter Zijlstra
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-26 8:50 ` Peter Zijlstra
2018-10-13 1:31 ` [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2) Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 22:33 ` Joel Fernandes
2018-10-15 22:33 ` Joel Fernandes
2018-10-15 22:33 ` Joel Fernandes
2018-10-15 22:33 ` Joel Fernandes
2018-10-15 22:33 ` Joel Fernandes
2018-10-15 22:33 ` Joel Fernandes
2018-10-15 22:33 ` Joel Fernandes
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 19:43 ` Joel Fernandes
2018-10-16 19:43 ` Joel Fernandes
2018-10-16 19:43 ` Joel Fernandes
2018-10-16 19:43 ` Joel Fernandes
2018-10-16 19:43 ` Joel Fernandes
2018-10-16 19:43 ` Joel Fernandes
2018-10-17 7:38 ` Vlastimil Babka
2018-10-17 7:38 ` Vlastimil Babka
2018-10-17 7:38 ` Vlastimil Babka
2018-10-17 7:38 ` Vlastimil Babka
2018-10-17 7:38 ` Vlastimil Babka
2018-10-17 7:38 ` Vlastimil Babka
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 11:57 ` Balbir Singh
2018-10-24 11:57 ` Balbir Singh
2018-10-24 11:57 ` Balbir Singh
2018-10-24 11:57 ` Balbir Singh
2018-10-24 11:57 ` Balbir Singh
2018-10-24 11:57 ` Balbir Singh
2018-10-24 11:57 ` Balbir Singh
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-26 21:11 ` Joel Fernandes
2018-10-29 10:28 ` Will Deacon [this message]
2018-10-29 10:28 ` Will Deacon
2018-10-29 10:28 ` Will Deacon
2018-10-29 10:28 ` Will Deacon
2018-10-29 10:28 ` Will Deacon
2018-10-29 10:28 ` Will Deacon
2018-10-29 10:28 ` Will Deacon
2018-10-25 2:13 ` Joel Fernandes
2018-10-25 2:13 ` Joel Fernandes
2018-10-25 2:13 ` Joel Fernandes
2018-10-25 2:13 ` Joel Fernandes
2018-10-25 2:13 ` Joel Fernandes
2018-10-25 2:13 ` Joel Fernandes
2018-10-25 2:13 ` Joel Fernandes
2018-10-27 10:21 ` Balbir Singh
2018-10-27 10:21 ` Balbir Singh
2018-10-27 10:21 ` Balbir Singh
2018-10-27 10:21 ` Balbir Singh
2018-10-27 10:21 ` Balbir Singh
2018-10-27 10:21 ` Balbir Singh
2018-10-27 10:21 ` Balbir Singh
2018-10-27 19:39 ` Joel Fernandes
2018-10-27 19:39 ` Joel Fernandes
2018-10-27 19:39 ` Joel Fernandes
2018-10-27 19:39 ` Joel Fernandes
2018-10-27 19:39 ` Joel Fernandes
2018-10-27 19:39 ` Joel Fernandes
2018-10-27 19:39 ` Joel Fernandes
2018-10-28 22:40 ` Balbir Singh
2018-10-28 22:40 ` Balbir Singh
2018-10-28 22:40 ` Balbir Singh
2018-10-28 22:40 ` Balbir Singh
2018-10-28 22:40 ` Balbir Singh
2018-10-28 22:40 ` Balbir Singh
2018-10-28 22:40 ` Balbir Singh
2018-10-13 1:31 ` [PATCH 3/4] arm64: select HAVE_MOVE_PMD for faster mremap (v1) Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:31 ` Joel Fernandes (Google)
2018-10-13 1:32 ` [PATCH 4/4] x86: " Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
2018-10-13 1:32 ` Joel Fernandes (Google)
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=20181029102840.GC13965@arm.com \
--to=will.deacon@arm.com \
--cc=anton.ivanov@kot-begemot.co.uk \
--cc=bsingharora@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=dalias@libc.org \
--cc=dancol@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=deller@gmx.de \
--cc=elfring@users.sourceforge.net \
--cc=hughd@google.com \
--cc=jejb@parisc-linux.org \
--cc=joel@joelfernandes.org \
--cc=jonas@southpole.se \
--cc=kasan-dev@googlegroups.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=lokeshgidra@google.com \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=x86@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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.