>> > powerpc, metag, sh, s390) do not?
>>
>> Potentially laziness/ignorance-of-feature? It looks like this feature
>> started on x86_64 and then spread
>> to arm*.
>
> Yes. In 3212b535f200c85b5a6 Steve Capper (ARM person) hoisted the code
> out of x86 int
,
powerpc, metag, sh, s390) do not?
Potentially laziness/ignorance-of-feature? It looks like this feature
started on x86_64 and then spread
to arm*.
Yes. In 3212b535f200c85b5a6 Steve Capper (ARM person) hoisted the code
out of x86 into generic, then made arm use it.
I tested the pmd sharing
filtered out events from being considered by
hist_entry_iter__add.
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Steve Capper
---
Hi,
This patch fixes my problem, but I don't know enough perf to
confidently state that this will work everywhere
filtered out events from being considered by
hist_entry_iter__add.
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Signed-off-by: Steve Capper steve.cap...@linaro.org
---
Hi,
This patch fixes
ror 2
make: *** Waiting for unfinished jobs
This patch adjusts the arm64 Makefile to reference the compiled library
explicitly (as is currently done in x86), rather than the directory.
Fixes: f4f75ad5 efi: efistub: Convert into static library
Signed-off-by: Steve Capper
---
arch/arm64/Makefile
: *** Waiting for unfinished jobs
This patch adjusts the arm64 Makefile to reference the compiled library
explicitly (as is currently done in x86), rather than the directory.
Fixes: f4f75ad5 efi: efistub: Convert into static library
Signed-off-by: Steve Capper steve.cap...@linaro.org
---
arch/arm64
On 17 February 2015 at 23:11, David Long wrote:
> From: Sandeepa Prabhu
>
> Kprobes needs simulation of instructions that cannot be stepped
> from different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is
On 17 February 2015 at 23:11, David Long dave.l...@linaro.org wrote:
From: Sandeepa Prabhu sandeepa.pra...@linaro.org
Kprobes needs simulation of instructions that cannot be stepped
from different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the
SS
>
> This patch should address the problem and is a fix to the mmotm patch
> mm-remove-remaining-references-to-numa-hinting-bits-and-helpers.patch
>
> Reported-by: Mark Brown
> Signed-off-by: Mel Gorman
Acked-by: Steve Capper
> ---
> include/linux/swapops.h | 2 +
-remove-remaining-references-to-numa-hinting-bits-and-helpers.patch
Reported-by: Mark Brown broo...@kernel.org
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Steve Capper steve.cap...@linaro.org
---
include/linux/swapops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 28 January 2015 at 15:24, Mark Brown wrote:
> For at least the past couple of days tests of libhugetlbfs have been
> hanging on mustang in the mlock test running ARMv8 defconfig with both
> 32 bit and 64 bit userspace - after the mprotect test (the one before
> it) we get no console output for
On 28 January 2015 at 15:24, Mark Brown wrote:
> For at least the past couple of days tests of libhugetlbfs have been
> hanging on mustang in the mlock test running ARMv8 defconfig with both
> 32 bit and 64 bit userspace - after the mprotect test (the one before
> it) we get no console output for
On 8 January 2015 at 18:48, Ard Biesheuvel wrote:
> In order to support kexec, the kernel needs to be able to deal with the
> state of the UEFI firmware after SetVirtualAddressMap() has been called.
> To avoid having separate code paths for non-kexec and kexec, let's move
> the call to
On 8 January 2015 at 18:48, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
In order to support kexec, the kernel needs to be able to deal with the
state of the UEFI firmware after SetVirtualAddressMap() has been called.
To avoid having separate code paths for non-kexec and kexec, let's move
On 28 January 2015 at 15:24, Mark Brown broo...@kernel.org wrote:
For at least the past couple of days tests of libhugetlbfs have been
hanging on mustang in the mlock test running ARMv8 defconfig with both
32 bit and 64 bit userspace - after the mprotect test (the one before
it) we get no
On 28 January 2015 at 15:24, Mark Brown broo...@kernel.org wrote:
For at least the past couple of days tests of libhugetlbfs have been
hanging on mustang in the mlock test running ARMv8 defconfig with both
32 bit and 64 bit userspace - after the mprotect test (the one before
it) we get no
On Sat, Jan 10, 2015 at 11:03:20PM -0500, David Long wrote:
> From: Sandeepa Prabhu
>
> AArch64 ISA does not have instructions to pop the PC register
> value from the stack(like ARM v7 has ldmia {...,pc}) without using
> one of the general purpose registers. This means return probes
> cannot
c.
> 2) I removed the addition of orig_x0 to ptrace.h.
> 3) Reorder the patches.
> 4) Replace the previous interrupt disabling (from Will Cohen) with
> an improved solution (from Steve Capper).
Hi David,
I've left feedback on the patches in the series.
I ran into two major issues:
1)
e Monitor are rejected too.
>
> System instructions are mostly enabled for stepping, except MSR
> immediate that updates "daif" flags in PSTATE, which are not safe
> for probing.
>
> Changes since v3:
> from David Long:
> 1) Removed unnecessary addtion of NOP afte
On Sat, Jan 10, 2015 at 11:03:16PM -0500, David Long wrote:
> From: "David A. Long"
>
> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>
> Signed-off-by: David A. Long
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/ptrace.h | 29 +
>
(from Will Cohen) with
an improved solution (from Steve Capper).
Hi David,
I've left feedback on the patches in the series.
I ran into two major issues:
1) trampoline_probe_handler had an errant call to:
kprobes_restore_local_irqflag (this caused crashes for me until
I removed
On Sat, Jan 10, 2015 at 11:03:20PM -0500, David Long wrote:
From: Sandeepa Prabhu sandeepa.pra...@linaro.org
AArch64 ISA does not have instructions to pop the PC register
value from the stack(like ARM v7 has ldmia {...,pc}) without using
one of the general purpose registers. This means
flags in PSTATE, which are not safe
for probing.
Changes since v3:
from David Long:
1) Removed unnecessary addtion of NOP after out-of-line instruction.
2) Replaced table-driven instruction parsing with calls to external
test functions.
from Steve Capper:
3) Disable local irq while
On Sat, Jan 10, 2015 at 11:03:16PM -0500, David Long wrote:
From: David A. Long dave.l...@linaro.org
Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
Signed-off-by: David A. Long dave.l...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ptrace.h
On 9 January 2015 at 12:13, Mark Rutland wrote:
> On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
>> On 01/05/2015 07:46 PM, Linus Torvalds wrote:
>> > It's a day delayed - not because of any particular development issues,
>> > but simply because I was tiling a bathroom yesterday.
On 9 January 2015 at 12:13, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
On 01/05/2015 07:46 PM, Linus Torvalds wrote:
It's a day delayed - not because of any particular development issues,
but simply because I was tiling a bathroom
On 12 December 2014 at 22:42, David Long wrote:
> On 12/10/14 11:38, Steve Capper wrote:
>>
>> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
>>>
>>> On 12/09/14 08:33, Steve Capper wrote:
>>>>
>>>> On Thu,
On 12 December 2014 at 22:42, David Long dave.l...@linaro.org wrote:
On 12/10/14 11:38, Steve Capper wrote:
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
> On 12/09/14 08:33, Steve Capper wrote:
> >On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
> >
> >Not sure if this is helpful, but the following also caused a crash f
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
Not sure if this is helpful, but the following also caused a crash for
me:
echo p:trace_event_buffer_lock_reserve
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
> (2014/12/04 20:29), Steve Capper wrote:
>
> >> I'd like to ask you to try my fix on your machine, with my reproducing
> >> methods. (do not use sytemtap nor perf, those can have other issues)
> &
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
(2014/12/04 20:29), Steve Capper wrote:
I'd like to ask you to try my fix on your machine, with my reproducing
methods. (do not use sytemtap nor perf, those can have other issues)
Thank you Masami,
I tried
On 4 December 2014 at 10:43, Masami Hiramatsu
wrote:
> (2014/12/04 19:21), Steve Capper wrote:
>> On 4 December 2014 at 02:48, David Long wrote:
>>> On 12/03/14 20:16, William Cohen wrote:
>>>
>>> [...]
>>>
>>>>
>>>> The p
On 4 December 2014 at 02:48, David Long wrote:
> On 12/03/14 20:16, William Cohen wrote:
>
> [...]
>
>>
>> The perf issue seems to be independent and can be reproduced without using
>> any kprobe support. I need to get a simple reproducer and mention it on the
>> linux-perf-user list.
>>
>>
On 4 December 2014 at 02:48, David Long dave.l...@linaro.org wrote:
On 12/03/14 20:16, William Cohen wrote:
[...]
The perf issue seems to be independent and can be reproduced without using
any kprobe support. I need to get a simple reproducer and mention it on the
linux-perf-user list.
On 4 December 2014 at 10:43, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2014/12/04 19:21), Steve Capper wrote:
On 4 December 2014 at 02:48, David Long dave.l...@linaro.org wrote:
On 12/03/14 20:16, William Cohen wrote:
[...]
The perf issue seems to be independent and can
On 27 November 2014 at 06:07, Masami Hiramatsu
wrote:
> (2014/11/27 3:59), Steve Capper wrote:
>> The crash is extremely easy to reproduce.
>>
>> I've not observed any missed events on a kprobe on an arm64 system
>> that's still alive.
>> My (limited!) un
On 27 November 2014 at 06:07, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2014/11/27 3:59), Steve Capper wrote:
The crash is extremely easy to reproduce.
I've not observed any missed events on a kprobe on an arm64 system
that's still alive.
My (limited!) understanding
On 26 November 2014 at 17:46, David Long wrote:
> On 11/26/14 05:03, Steve Capper wrote:
>>
>> On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
>>>
>>> (2014/11/21 0:02), Steve Capper wrote:
>>>>
>>>> On Tue, Nov 18, 201
On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
> (2014/11/21 0:02), Steve Capper wrote:
> > On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
> >> From: "David A. Long"
> >>
> >> This patchset is heavily based on Sandeep
On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
(2014/11/21 0:02), Steve Capper wrote:
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
From: David A. Long dave.l...@linaro.org
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes
patches
On 26 November 2014 at 17:46, David Long dave.l...@linaro.org wrote:
On 11/26/14 05:03, Steve Capper wrote:
On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
(2014/11/21 0:02), Steve Capper wrote:
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
From: David
Even when the debug symbols have been correctly installed (and loaded
by perf).
This patch adds logic to dso__load_sym to query syms_ss for the
.debug_frame section if it can't be found in the elf file pointed to by
runtime_ss.
Signed-off-by: Steve Capper
---
This patch is against 3.18-rc5.
---
the debug symbols have been correctly installed (and loaded
by perf).
This patch adds logic to dso__load_sym to query syms_ss for the
.debug_frame section if it can't be found in the elf file pointed to by
runtime_ss.
Signed-off-by: Steve Capper steve.cap...@linaro.org
---
This patch is against 3.18-rc5
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
> From: "David A. Long"
>
> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> first
> seen in October 2013. This version attempts to address concerns raised by
> reviewers and also fixes problems discovered
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
From: David A. Long dave.l...@linaro.org
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
first
seen in October 2013. This version attempts to address concerns raised by
reviewers and also fixes
On Wed, Oct 29, 2014 at 01:49:44PM +0530, Aneesh Kumar K.V wrote:
> Update generic gup implementation with powerpc specific details.
> On powerpc at pmd level we can have hugepte, normal pmd pointer
> or a pointer to the hugepage directory.
>
> Signed-off-by: Aneesh Kumar K.V
...@linux.vnet.ibm.com
Acked-by: Steve Capper steve.cap...@linaro.org
Thanks Aneesh,
--
Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Mon, Oct 27, 2014 at 06:43:27PM -0400, David Miller wrote:
> From: Andrew Morton
> Date: Mon, 27 Oct 2014 14:09:38 -0700
>
> > Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
> >
> > We really should switch x86 to the generic version - from a quick read
> > it looks like it
On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote:
> On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman
> wrote:
>
> > On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
> > > On Sat, 25 Oct 2014 16:14:19 +0530 "Aneesh Kumar K.V"
> > > wrote:
> > >
> > > > Update generic
(*pgdp))
> + if (pgd_none(pgd))
> break;
> - else if (!gup_pud_range(pgdp, addr, next, write, pages, ))
> + if (unlikely(pgd_huge(pgd))) {
> + if (!gup_huge_pte(__pte(pgd_val(pgd)), (pte_t *)pgdp,
> +
(unsigned long start, int
nr_pages, int write,
return ret;
}
-
#endif /* CONFIG_HAVE_GENERIC_RCU_GUP */
--
With the above changes (remove the arch/arm and arch/arm64 changes and
add an extra assumption to the list for gup_huge_pte):
Acked-by: Steve Capper steve.cap...@linaro.org
Also
On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote:
On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman m...@ellerman.id.au
wrote:
On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
On Sat, 25 Oct 2014 16:14:19 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com
On Mon, Oct 27, 2014 at 06:43:27PM -0400, David Miller wrote:
From: Andrew Morton a...@linux-foundation.org
Date: Mon, 27 Oct 2014 14:09:38 -0700
Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
We really should switch x86 to the generic version - from a quick read
it
On 24 October 2014 00:40, Benjamin Herrenschmidt
wrote:
> On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
>> Hey guys, was looking over the generic GUP while working on a sparc64
>> issue and I noticed that you guys do speculative page gets, and after
>> talking with Johannes Weiner
On 24 October 2014 00:40, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with
t; mm/gup.c | 113
> +++
> 4 files changed, 84 insertions(+), 59 deletions(-)
>
Hi Aneesh,
Thanks for coding this up. I've tested this for arm (Arndale board) and
arm64 (Juno); it builds without any issues and passes my futex on THP
| 113
+++
4 files changed, 84 insertions(+), 59 deletions(-)
Hi Aneesh,
Thanks for coding this up. I've tested this for arm (Arndale board) and
arm64 (Juno); it builds without any issues and passes my futex on THP
tail test.
Please add my:
Tested-by: Steve
On Thu, Oct 16, 2014 at 08:48:20PM +0530, Aneesh Kumar K.V wrote:
> Steve Capper writes:
>
> > On Wed, Oct 15, 2014 at 10:04:47PM +0530, Aneesh Kumar K.V wrote:
> >> Update generic gup implementation with powerpc specific details.
> >> On powerpc at pmd level w
eers,
--
Steve
>From 2fb7b0308f0aca94c50611257ba82d656abb0768 Mon Sep 17 00:00:00 2001
From: Steve Capper
Date: Thu, 16 Oct 2014 09:09:48 +0100
Subject: [PATCH] Fixup for Update generic gup implementation
The patch:
mm: Update generic gup implementation to handle hugepage directory
will n
).
Cheers,
--
Steve
From 2fb7b0308f0aca94c50611257ba82d656abb0768 Mon Sep 17 00:00:00 2001
From: Steve Capper steve.cap...@linaro.org
Date: Thu, 16 Oct 2014 09:09:48 +0100
Subject: [PATCH] Fixup for Update generic gup implementation
The patch:
mm: Update generic gup implementation to handle
On Thu, Oct 16, 2014 at 08:48:20PM +0530, Aneesh Kumar K.V wrote:
Steve Capper steve.cap...@linaro.org writes:
On Wed, Oct 15, 2014 at 10:04:47PM +0530, Aneesh Kumar K.V wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte
On Tue, Oct 14, 2014 at 05:38:43PM +0530, Aneesh Kumar K.V wrote:
> Steve Capper writes:
>
> > On Tue, Oct 14, 2014 at 04:27:53PM +0530, Aneesh Kumar K.V wrote:
> >> get_user_pages_fast attempts to pin user pages by walking the page
> >> tables directly and avoids
On Tue, Oct 14, 2014 at 04:27:53PM +0530, Aneesh Kumar K.V wrote:
> get_user_pages_fast attempts to pin user pages by walking the page
> tables directly and avoids taking locks. Thus the walker needs to be
> protected from page table pages being freed from under it, and needs
> to block any THP
On Tue, Oct 14, 2014 at 04:27:53PM +0530, Aneesh Kumar K.V wrote:
get_user_pages_fast attempts to pin user pages by walking the page
tables directly and avoids taking locks. Thus the walker needs to be
protected from page table pages being freed from under it, and needs
to block any THP
On Tue, Oct 14, 2014 at 05:38:43PM +0530, Aneesh Kumar K.V wrote:
Steve Capper steve.cap...@linaro.org writes:
On Tue, Oct 14, 2014 at 04:27:53PM +0530, Aneesh Kumar K.V wrote:
get_user_pages_fast attempts to pin user pages by walking the page
tables directly and avoids taking locks. Thus
On Thu, Sep 04, 2014 at 10:41:52AM +0100, Catalin Marinas wrote:
> Hi Zhichang,
>
> (cc'ing Steve Capper for the huge page stuff)
>
> On Fri, Aug 22, 2014 at 01:38:26PM +0100, zhichang.yuan wrote:
> > I am working to implement the DEBUG_PAGEALLOC on ARMv8.
>
> I ass
On Thu, Sep 04, 2014 at 10:41:52AM +0100, Catalin Marinas wrote:
Hi Zhichang,
(cc'ing Steve Capper for the huge page stuff)
On Fri, Aug 22, 2014 at 01:38:26PM +0100, zhichang.yuan wrote:
I am working to implement the DEBUG_PAGEALLOC on ARMv8.
I assume that's the arm64 kernel.
After
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Acked-by: Catalin Marinas
> Signed-off-by: Minchan Kim
Acked-by: Steve Capper
--
To unsubscribe from this list: send the line "uns
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim
This patch looks good to me:
Acked-by: Steve Capper
There is another patch that introduces a helper function
Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Minchan Kim minc...@kernel.org
This patch looks good to me:
Acked-by: Steve Capper steve.cap
Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Minchan Kim minc...@kernel.org
Acked
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim
> ---
> arch/arm/include/asm/pgtable-3level.h | 3 +++
> arch/arm64/include/asm/pgtable.h | 2 ++
Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Minchan Kim minc...@kernel.org
---
arch/arm/include/asm/pgtable-3level.h | 3 +++
arch
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim
> ---
> arch/arm64/include/asm/pgtable.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --
Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Minchan Kim minc...@kernel.org
---
arch/arm64/include/asm/pgtable.h | 2 ++
1 file changed
).
> >
> > I'm happy for any fix which can be included in 3.16.
>
> Steve Capper made a point about performance. He'll follow up.
Hi :-).
My concern was initially about splitting THPs, as with a 64K granule,
we will have 2048 calls to set_pte_at in a loop. Having thought about
it, t
() like create_mapping(), I think kvm_set_pte() as
well.
So I'm proposing an alternative patch (which needs some benchmarking as
well to see if anything is affected, maybe application startup time).
I'm happy for any fix which can be included in 3.16.
Steve Capper made a point
On 15 May 2014 17:27, Mark Salter wrote:
> On Thu, 2014-05-15 at 15:44 +0100, Steve Capper wrote:
>> On Thu, May 15, 2014 at 10:19:22AM -0400, Mark Salter wrote:
>> > The following happens when trying to run a kvm guest on a kernel
>> > configured for 64k pages. This d
On Thu, May 15, 2014 at 10:19:22AM -0400, Mark Salter wrote:
> The following happens when trying to run a kvm guest on a kernel
> configured for 64k pages. This doesn't happen with 4k pages:
>
> BUG: failure at include/linux/mm.h:297/put_page_testzero()!
> Kernel panic - not syncing: BUG!
>
On Thu, May 15, 2014 at 10:19:22AM -0400, Mark Salter wrote:
The following happens when trying to run a kvm guest on a kernel
configured for 64k pages. This doesn't happen with 4k pages:
BUG: failure at include/linux/mm.h:297/put_page_testzero()!
Kernel panic - not syncing: BUG!
CPU:
On 15 May 2014 17:27, Mark Salter msal...@redhat.com wrote:
On Thu, 2014-05-15 at 15:44 +0100, Steve Capper wrote:
On Thu, May 15, 2014 at 10:19:22AM -0400, Mark Salter wrote:
The following happens when trying to run a kvm guest on a kernel
configured for 64k pages. This doesn't happen
64_4_LEVELS
> +static inline void __pud_free_tlb(struct mmu_gather *tlb, pmd_t *pudp,
> + unsigned long addr)
The second parameter needs to be a pointer to pud_t ?
(this fires up a warning with STRICT_MM_TYPECHECKS).
With that and Christoffer's feedback about expanding the comments on
create_
)
The second parameter needs to be a pointer to pud_t ?
(this fires up a warning with STRICT_MM_TYPECHECKS).
With that and Christoffer's feedback about expanding the comments on
create_pud_entry addressed:
Reviewed-by: Steve Capper steve.cap...@linaro.org
Cheers,
--
Steve
--
To unsubscribe from this list
On Fri, May 02, 2014 at 11:20:33AM -0400, Mark Salter wrote:
> As explained in more detail in the second patch, I have observed a soft
> lockup under some loads. These lockups were in flush_tlb_kernel_range()
> which was looping through a very large address range. While looking into
> this, I also
On Fri, May 02, 2014 at 11:20:33AM -0400, Mark Salter wrote:
As explained in more detail in the second patch, I have observed a soft
lockup under some loads. These lockups were in flush_tlb_kernel_range()
which was looping through a very large address range. While looking into
this, I also
On Sun, Apr 27, 2014 at 12:37:35PM +0900, Jungseok Lee wrote:
> On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote:
> > On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
[ ... ]
> >
> > This is overly complicated. For <4 levels we set x0 to be:
> &
On Sun, Apr 27, 2014 at 12:37:35PM +0900, Jungseok Lee wrote:
On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote:
On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
[ ... ]
This is overly complicated. For 4 levels we set x0 to be:
ttbr1 + 2*PAGE_SIZE. For 4-levels, we
On 24 April 2014 12:03, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 11:55:56AM +0100, Steve Capper wrote:
>> On 24 April 2014 11:42, Russell King - ARM Linux
>> wrote:
>> > On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
>> >&g
On 24 April 2014 11:42, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
>> I guess I'm after some commitment that this is (a) useful to somebody and
>> (b) going to be tested regularly, otherwise it will go the way of things
>> like big-endian, where
On Wed, Apr 16, 2014 at 12:46:38PM +0100, Steve Capper wrote:
> Hello,
> This series brings HugeTLB pages and Transparent Huge Pages (THP) to
> ARM on short descriptors.
>
> Russell, Andrew,
> I would like to get this in next (and hopefully 3.16 if no problems
> arise) if t
On Wed, Apr 16, 2014 at 12:46:38PM +0100, Steve Capper wrote:
Hello,
This series brings HugeTLB pages and Transparent Huge Pages (THP) to
ARM on short descriptors.
Russell, Andrew,
I would like to get this in next (and hopefully 3.16 if no problems
arise) if that sounds reasonable
On 24 April 2014 11:42, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
I guess I'm after some commitment that this is (a) useful to somebody and
(b) going to be tested regularly, otherwise it will go the way of things
like
On 24 April 2014 12:03, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Thu, Apr 24, 2014 at 11:55:56AM +0100, Steve Capper wrote:
On 24 April 2014 11:42, Russell King - ARM Linux li...@arm.linux.org.uk
wrote:
On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
I guess
On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
> This patch implements 4 levels of translation tables since 3 levels
> of page tables with 4KB pages cannot support 40-bit physical address
> space described in [1] due to the following issue.
>
> It is a restriction that kernel
On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.
It is a restriction that kernel logical
page VMAs are added to
the flush range.
Signed-off-by: Steve Capper
---
arch/arm/include/asm/tlb.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 0baf7f0..b2498e6 100644
--- a/arch/arm/include/asm/tlb.h
Introduce huge pte versions of pte_page, pte_present and pte_young.
This allows ARM (without LPAE) to use alternative pte processing logic
for huge ptes.
Generic implementations that call the standard pte versions are also
added to asm-generic/hugetlb.h.
Signed-off-by: Steve Capper
Acked
and
sections.
Signed-off-by: Steve Capper
---
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/pgtable-2level.h | 32
arch/arm/include/asm/pgtable-3level.h | 1 +
arch/arm/include/asm/pgtable.h| 2 --
arch/arm/include/asm/tlb.h
Rather than take a pte_t as an input, break this down to the pfn
and whether or not the memory is executable.
This allows us to use this function for ptes and pmds.
Signed-off-by: Steve Capper
---
arch/arm/include/asm/pgtable.h | 6 +++---
arch/arm/mm/flush.c| 9 -
2 files
101 - 200 of 240 matches
Mail list logo
