o memory
map design document, [1], saying 1GB aligned RAM. The majority of arm64
platforms might follow the information although it is not spec. IOW,
a machine I've played was at least unusual *at that time*, so I didn't
consider upstream work.
[1]
http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf
Best Regards
Jungseok Lee
o memory
map design document, [1], saying 1GB aligned RAM. The majority of arm64
platforms might follow the information although it is not spec. IOW,
a machine I've played was at least unusual *at that time*, so I didn't
consider upstream work.
[1]
http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf
Best Regards
Jungseok Lee
On Nov 17, 2015, at 12:55 AM, Tejun Heo wrote:
Dear Tejun,
> On Wed, Nov 04, 2015 at 01:26:07PM +0000, Jungseok Lee wrote:
>> As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
>> used any more. That is, no code refers to the definition.
>>
>>
On Nov 17, 2015, at 12:55 AM, Tejun Heo wrote:
Dear Tejun,
> On Wed, Nov 04, 2015 at 01:26:07PM +0000, Jungseok Lee wrote:
>> As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
>> used any more. That is, no code refers to the definition.
>>
>> Ack
(+ Li Bin in CC)
On Nov 10, 2015, at 11:42 AM, AKASHI Takahiro wrote:
> On 11/09/2015 11:04 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> Function graph tracer modifies a return address (LR) in a stack
(+ Li Bin in CC)
On Nov 10, 2015, at 11:42 AM, AKASHI Takahiro wrote:
> On 11/09/2015 11:04 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> Function graph tracer modifies a return address (LR) in a stack
On Nov 11, 2015, at 2:03 PM, AKASHI Takahiro wrote:
> Jungseok,
>
> On 11/10/2015 11:05 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> Stack tracer on arm64, check_stack(), is uniqeue in the foll
On Nov 11, 2015, at 2:03 PM, AKASHI Takahiro wrote:
> Jungseok,
>
> On 11/10/2015 11:05 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> Stack tracer on arm64, check_stack(), is uniqeue in the foll
(reg1 == AARCH64_INSN_REG_29) &&
> + (reg2 == AARCH64_INSN_REG_30) &&
> + (base == AARCH64_INSN_REG_SP)) {
> + /*
> + * stp x29, x3
@ __AARCH64_INSN_FUNCS(hint,0xF01F, 0xD503201F)
> __AARCH64_INSN_FUNCS(br, 0xFC1F, 0xD61F)
> __AARCH64_INSN_FUNCS(blr, 0xFC1F, 0xD63F)
> __AARCH64_INSN_FUNCS(ret, 0xFC1F, 0xD65F)
> +__AARCH64_INSN_FUNCS(eret, 0x, 0xD69F00E0)
Accordin
On Nov 10, 2015, at 11:58 AM, AKASHI Takahiro wrote:
Hi Akashi,
> On 11/09/2015 11:24 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> This is the fifth patch series for fixing stack tracer on arm64.
AARCH64_INSN_LDST_STORE_PAIR) &&
> + (reg1 == AARCH64_INSN_REG_29) &&
> + (reg2 == AARCH64_INSN_REG_30) &&
> + (base == AARCH64_INSN_REG_SP)) {
> + /*
> +
On Nov 10, 2015, at 11:58 AM, AKASHI Takahiro wrote:
Hi Akashi,
> On 11/09/2015 11:24 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> This is the fifth patch series for fixing stack tracer on arm64.
FF, 0xD69F00E0)
According to C4.2.7, the third argument looks like 0xD69F03E0. Rn field is 1
in case of eret.
Best Regards
Jungseok Lee
> #undef__AARCH64_INSN_FUNCS
>
> @@ -370,6 +375,19 @@ bool aarch32_insn_is_wide(u32 insn);
> u32 aarch32
nel/debug/tracing/current_tracer
$ [ Run any workload ]
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Best Regards
Jungseok Lee
--
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 at http://www.tux.org/lkml/
t;
> data.trace = trace;
> data.skip = trace->skip;
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + data.ret_stack_index = current->curr_ret_stack;
Can I get an idea on why current->curr_ret_stack is used instead of
tsk->curr_ret_stack?
Best Regards
Jungseok Lee--
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 at http://www.tux.org/lkml/
, struct
> stack_trace *trace)
>
> data.trace = trace;
> data.skip = trace->skip;
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + data.ret_stack_index = current->curr_ret_stack;
Can I get an idea on why current->curr_ret_stack is used instead of
tsk->curr_ret_stack?
Best Regards
Jungseok Lee--
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 at http://www.tux.org/lkml/
nel/debug/tracing/current_tracer
$ [ Run any workload ]
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Best Regards
Jungseok Lee
--
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 at http://www.tux.org/lkml/
On Nov 4, 2015, at 2:58 AM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 03/11/15 13:49, Jungseok Lee wrote:
>> Additionally, I've been thinking of do_softirq_own_stack() which is your
>> another comment [3]. Recently, I've realized there is possibility that
>> I misu
As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
used any more. That is, no code refers to the definition.
Acked-by: Christoph Lameter
Signed-off-by: Jungseok Lee
---
I've kept Acked-by from Christoph since there is no change in generic
percpu code between v1 and v2.
Changes
On Nov 4, 2015, at 7:07 AM, Tejun Heo wrote:
> Hello,
Hello,
> On Tue, Nov 03, 2015 at 11:12:51PM +0900, Jungseok Lee wrote:
>> On Nov 3, 2015, at 4:10 AM, Tejun Heo wrote:
>>
>> Dear Tejun,
>>
>>> On Sun, Nov 01, 2015 at 07:46:15AM +, Jungseok Lee
As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
used any more. That is, no code refers to the definition.
Acked-by: Christoph Lameter <c...@linux.com>
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
I've kept Acked-by from Christoph since there
On Nov 4, 2015, at 2:58 AM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 03/11/15 13:49, Jungseok Lee wrote:
>> Additionally, I've been thinking of do_softirq_own_stack() which is your
>> another comment [3]. Recently, I've realized there is possibility that
>> I misu
On Nov 4, 2015, at 7:07 AM, Tejun Heo wrote:
> Hello,
Hello,
> On Tue, Nov 03, 2015 at 11:12:51PM +0900, Jungseok Lee wrote:
>> On Nov 3, 2015, at 4:10 AM, Tejun Heo wrote:
>>
>> Dear Tejun,
>>
>>> On Sun, Nov 01, 2015 at 07:46:15AM +, Jungseok Lee
On Nov 3, 2015, at 4:10 AM, Tejun Heo wrote:
Dear Tejun,
> On Sun, Nov 01, 2015 at 07:46:15AM +0000, Jungseok Lee wrote:
>> As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
>> used any more. That is, no code refers to the definition.
>>
>>
On Nov 3, 2015, at 1:10 AM, Christoph Lameter wrote:
Dear Christoph,
> On Sun, 1 Nov 2015, Jungseok Lee wrote:
>
>> There is no room to adjust 'atom_size' now when a generic percpu area
>> is used. It would be redundant to write down an architecture-specific
>> setup_
On Nov 3, 2015, at 1:22 AM, Catalin Marinas wrote:
Hi Catalin,
> On Mon, Nov 02, 2015 at 10:10:23AM -0600, Christoph Lameter wrote:
>> On Sun, 1 Nov 2015, Jungseok Lee wrote:
>>
>>> There is no room to adjust 'atom_size' now when a generic percpu area
>>> is use
On Nov 3, 2015, at 4:10 AM, Tejun Heo wrote:
Dear Tejun,
> On Sun, Nov 01, 2015 at 07:46:15AM +0000, Jungseok Lee wrote:
>> As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
>> used any more. That is, no code refers to the definition.
>>
>>
On Nov 3, 2015, at 1:22 AM, Catalin Marinas wrote:
Hi Catalin,
> On Mon, Nov 02, 2015 at 10:10:23AM -0600, Christoph Lameter wrote:
>> On Sun, 1 Nov 2015, Jungseok Lee wrote:
>>
>>> There is no room to adjust 'atom_size' now when a generic percpu area
>>> is use
On Nov 3, 2015, at 1:10 AM, Christoph Lameter wrote:
Dear Christoph,
> On Sun, 1 Nov 2015, Jungseok Lee wrote:
>
>> There is no room to adjust 'atom_size' now when a generic percpu area
>> is used. It would be redundant to write down an architecture-specific
>> setup_
idea on how to test the function prologue analyzer? It pretty
tough to compare stack trace data with objdump one. Is there an easier way
to observe this enhancement without objdump?
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
gt;ret_stack_index--].ret
> + - AARCH64_INSN_SIZE;
> + }
> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> +
This hunk would be affected as the commit, "ARM64: unwind: Fix PC calculation",
e306dfd0, has been reverted.
Best R
As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
used any more. That is, no code refers to the definition.
Signed-off-by: Jungseok Lee
---
include/linux/percpu.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index
.
Thanks in advance!
Best Regards
Jungseok Lee
Changes since v5:
- Introduced a new definition for 'atom_size' configuration
- Used PERCPU for stack allocation, per Catalin
Changes since v4:
- Supported 64KB page system
- Introduced IRQ_STACK_* macro, per Catalin
- Rebased on top of for-next
-by: James Morse
Signed-off-by: Jungseok Lee
---
Note that this change has been tested with 4 different combos:
- THREAD_SIZE = 16KB, IRQ_STACK_SIZE = 16KB
- THREAD_SIZE = 16KB, IRQ_STACK_SIZE = 8KB
- THREAD_SIZE = 8KB, IRQ_STACK_SIZE = 16KB
- THREAD_SIZE = 8KB, IRQ_STACK_SIZE = 8KB
I've reviwed
. The value could be updated if needed by architecture.
Signed-off-by: Jungseok Lee
---
include/linux/percpu.h | 4
mm/percpu.c| 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index 4bc6daf..57a2f16 100644
.
Can I get an idea on how to test the function prologue analyzer? It pretty
tough to compare stack trace data with objdump one. Is there an easier way
to observe this enhancement without objdump?
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubsc
current->ret_stack[data->ret_stack_index--].ret
> + - AARCH64_INSN_SIZE;
> + }
> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> +
This hunk would be affected as the commit, "ARM64: unwind: Fix PC calculation"
<takahiro.aka...@linaro.org>
Tested-by: James Morse <james.mo...@arm.com>
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
Note that this change has been tested with 4 different combos:
- THREAD_SIZE = 16KB, IRQ_STACK_SIZE = 16KB
- THREAD_SIZE = 16KB, IRQ_STACK_SIZE = 8KB
-
. The value could be updated if needed by architecture.
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
include/linux/percpu.h | 4
mm/percpu.c| 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index 4
.
Thanks in advance!
Best Regards
Jungseok Lee
Changes since v5:
- Introduced a new definition for 'atom_size' configuration
- Used PERCPU for stack allocation, per Catalin
Changes since v4:
- Supported 64KB page system
- Introduced IRQ_STACK_* macro, per Catalin
- Rebased on top of for-next
As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
used any more. That is, no code refers to the definition.
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
include/linux/percpu.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/percpu.h b/i
On Oct 8, 2015, at 11:45 PM, Jungseok Lee wrote:
> On Oct 8, 2015, at 7:01 PM, AKASHI Takahiro wrote:
>
> Hi Akashi,
>
>> This is the third patch series for fixing stack tracer on arm64.
>> The original issue was reported by Jungseok[1], and then I found more
>> i
On Oct 8, 2015, at 11:45 PM, Jungseok Lee wrote:
> On Oct 8, 2015, at 7:01 PM, AKASHI Takahiro wrote:
>
> Hi Akashi,
>
>> This is the third patch series for fixing stack tracer on arm64.
>> The original issue was reported by Jungseok[1], and then I found more
>> i
On Oct 20, 2015, at 10:08 PM, Jungseok Lee wrote:
> On Oct 20, 2015, at 1:18 AM, Catalin Marinas wrote:
>
> Hi Catalin,
>
>> On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
>>> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
>>>> B
On Oct 21, 2015, at 1:04 AM, James Morse wrote:
> On 20/10/15 16:05, Jungseok Lee wrote:
>> On Oct 20, 2015, at 7:05 PM, James Morse wrote:
>>> On 17/10/15 15:27, Jungseok Lee wrote:
>>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
>
On Oct 21, 2015, at 9:14 PM, Jungseok Lee wrote:
Whoops!
> [Only Akashi and James]
>
> On Oct 21, 2015, at 3:38 PM, AKASHI Takahiro wrote:
>
> Hi Akashi and James,
>
> Am I the only person who have experienced kernel panic with this series?
> I have observed N
ich is queued into for-next/core.
Best Regards
Jungseok Lee
> On 10/20/2015 10:26 PM, Jungseok Lee wrote:
>> On Oct 20, 2015, at 5:00 PM, AKASHI Takahiro wrote:
>>> This patch allows unwind_frame() to traverse from interrupt stack
>>> to process stack correctly by having a dummy
t;Interrupt stack", stack,
> + stack + sizeof(struct pt_regs), false);
According to entry.S in case of \el == 1, the stack, might look as follows.
--- <- High address (x21)
| |
| |
| pt_regs |
| |
|
On Oct 20, 2015, at 10:08 PM, Jungseok Lee wrote:
> On Oct 20, 2015, at 1:18 AM, Catalin Marinas wrote:
>
> Hi Catalin,
>
>> On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
>>> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
>>>> B
On Oct 21, 2015, at 1:04 AM, James Morse wrote:
> On 20/10/15 16:05, Jungseok Lee wrote:
>> On Oct 20, 2015, at 7:05 PM, James Morse wrote:
>>> On 17/10/15 15:27, Jungseok Lee wrote:
>>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
>
ned long *)(frame.fp + 0x18);
> + dump_mem("", "Interrupt stack", stack,
> + stack + sizeof(struct pt_regs), false);
According to entry.S in case of \el == 1, the stack, might look as follows.
--- <- High address (x21)
| |
| |
ich is queued into for-next/core.
Best Regards
Jungseok Lee
> On 10/20/2015 10:26 PM, Jungseok Lee wrote:
>> On Oct 20, 2015, at 5:00 PM, AKASHI Takahiro wrote:
>>> This patch allows unwind_frame() to traverse from interrupt stack
>>> to process stack correctly by having a dummy
On Oct 21, 2015, at 9:14 PM, Jungseok Lee wrote:
Whoops!
> [Only Akashi and James]
>
> On Oct 21, 2015, at 3:38 PM, AKASHI Takahiro wrote:
>
> Hi Akashi and James,
>
> Am I the only person who have experienced kernel panic with this series?
> I have observed N
On Oct 20, 2015, at 7:05 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 17/10/15 15:27, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8
.9.5
How about folding the following hunk into this patch?
The comment would be helpful for people to follow this code.
8<
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index f1303c5..0ff7db3 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@
On Oct 19, 2015, at 3:47 PM, AKASHI Takahiro wrote:
> Jungseok,
>
> On 10/15/2015 10:39 PM, Jungseok Lee wrote:
>> On Oct 15, 2015, at 1:19 PM, AKASHI Takahiro wrote:
>>> Jungseok,
>>
>>>>> 8<
>>>>> diff --git a/arch/arm64
On Oct 19, 2015, at 3:54 PM, AKASHI Takahiro wrote:
Hi Akashi,
> On 10/17/2015 11:27 PM, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8KB one. T
On Oct 20, 2015, at 1:18 AM, Catalin Marinas wrote:
Hi Catalin,
> On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
>> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
>>> BTW, a static allocation (DEFINE_PER_CPU for the whole irq stack) would
>>>
On Oct 20, 2015, at 7:05 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 17/10/15 15:27, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8
On Oct 19, 2015, at 3:47 PM, AKASHI Takahiro wrote:
> Jungseok,
>
> On 10/15/2015 10:39 PM, Jungseok Lee wrote:
>> On Oct 15, 2015, at 1:19 PM, AKASHI Takahiro wrote:
>>> Jungseok,
>>
>>>>> 8<
>>>>> diff --git a/arch/arm64
t;*/
> --
> 1.7.9.5
How about folding the following hunk into this patch?
The comment would be helpful for people to follow this code.
8<
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index f1303c5..0ff7db3 100644
--- a/arch/arm64/kernel/entry.S
+++
On Oct 20, 2015, at 1:18 AM, Catalin Marinas wrote:
Hi Catalin,
> On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
>> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
>>> BTW, a static allocation (DEFINE_PER_CPU for the whole irq stack) would
>>>
On Oct 19, 2015, at 3:54 PM, AKASHI Takahiro wrote:
Hi Akashi,
> On 10/17/2015 11:27 PM, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8KB one. T
Morse
Signed-off-by: Jungseok Lee
---
I've used Cc', not Tested-by tag, from James, since there is a gap
between v4 and v5.
Changes since v4:
- Supported 64KB page system
- Introduced IRQ_STACK_* macro, per Catalin
- Rebased on top of for-next/core
Changes since v3:
- Expanded stack trace
Cc: James Morse
Cc: Mark Rutland
Signed-off-by: Jungseok Lee
---
Changes since v2:
- Fixed a typo and mixed data in the commit msg
Changes since v1:
- Added an example to the commit msg, per Will
- Modified a comment
arch/arm64/kernel/traps.c | 15 ++-
1 file changed, 10 inserti
On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
Hi Catalin,
> On Fri, Oct 16, 2015 at 10:01:20PM +0900, Jungseok Lee wrote:
>> On Oct 16, 2015, at 12:59 AM, James Morse wrote:
>>> My concern is there could be push-back from the maintainer of
>>> ke
On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
Hi Catalin,
> On Fri, Oct 16, 2015 at 10:01:20PM +0900, Jungseok Lee wrote:
>> On Oct 16, 2015, at 12:59 AM, James Morse wrote:
>>> My concern is there could be push-back from the maintainer of
>>> ke
aka...@linaro.org>
Cc: James Morse <james.mo...@arm.com>
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
I've used Cc', not Tested-by tag, from James, since there is a gap
between v4 and v5.
Changes since v4:
- Supported 64KB page system
- Introduced IRQ_STACK_* macro, per
iro <takahiro.aka...@linaro.org>
Cc: James Morse <james.mo...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
Changes since v2:
- Fixed a typo and mixed data in the commit msg
Changes since v1:
- Added an exa
Cc: James Morse
Cc: Mark Rutland
Signed-off-by: Jungseok Lee
---
Changes since v1:
- Added an example to the commit msg, per Will
- Modified a comment.
arch/arm64/kernel/traps.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/a
On Oct 16, 2015, at 1:01 AM, James Morse wrote:
> On 15/10/15 15:24, Jungseok Lee wrote:
>> On Oct 9, 2015, at 11:24 PM, James Morse wrote:
>>> I think unwind_frame() needs to walk the irq stack too. [2] is an example
>>> of perf tracing back to userspace, (and th
On Oct 16, 2015, at 12:59 AM, James Morse wrote:
Hi James,
> On 14/10/15 13:12, Jungseok Lee wrote:
>> On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote:
>>> On Oct 13, 2015, at 8:00 PM, James Morse wrote:
>>>> On 12/10/15 23:13, Jungseok Lee wrote:
>>>>
On Oct 16, 2015, at 2:26 AM, Will Deacon wrote:
Hi Will,
> On Thu, Oct 15, 2015 at 01:21:54PM +0000, Jungseok Lee wrote:
>> dump_backtrace() has its own backtrace logic unlike perf callchain which
>> relies on walk_stackframe(). They behave differently when a symbol is
>>
On Oct 16, 2015, at 2:26 AM, Will Deacon wrote:
Hi Will,
> On Thu, Oct 15, 2015 at 01:21:54PM +0000, Jungseok Lee wrote:
>> dump_backtrace() has its own backtrace logic unlike perf callchain which
>> relies on walk_stackframe(). They behave differently when a symbol is
>>
On Oct 16, 2015, at 12:59 AM, James Morse wrote:
Hi James,
> On 14/10/15 13:12, Jungseok Lee wrote:
>> On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote:
>>> On Oct 13, 2015, at 8:00 PM, James Morse wrote:
>>>> On 12/10/15 23:13, Jungseok Lee wrote:
>>>>
On Oct 16, 2015, at 1:01 AM, James Morse wrote:
> On 15/10/15 15:24, Jungseok Lee wrote:
>> On Oct 9, 2015, at 11:24 PM, James Morse wrote:
>>> I think unwind_frame() needs to walk the irq stack too. [2] is an example
>>> of perf tracing back to userspace, (and th
iro <takahiro.aka...@linaro.org>
Cc: James Morse <james.mo...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Jungseok Lee <jungseokle...@gmail.com>
---
Changes since v1:
- Added an example to the commit msg, per Will
- Modified a comment.
arch/arm64/kernel/trap
p 10
> [1] sudo ./perf report --call-graph --stdio
> [2] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On Oct 15, 2015, at 1:19 PM, AKASHI Takahiro wrote:
> Jungseok,
Hi Akashi,
> On 10/14/2015 09:55 PM, Jungseok Lee wrote:
>> On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
>>> On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
>>>> On 10/09/2015 11:24 PM, Jam
head.S and unwind_frame() structure
for a few of symbols in *.S, so this hunk does not take care of the case.
Cc: AKASHI Takahiro
Cc: James Morse
Cc: Mark Rutland
Signed-off-by: Jungseok Lee
---
arch/arm64/kernel/traps.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff
p 10
> [1] sudo ./perf report --call-graph --stdio
> [2] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On Oct 15, 2015, at 1:19 PM, AKASHI Takahiro wrote:
> Jungseok,
Hi Akashi,
> On 10/14/2015 09:55 PM, Jungseok Lee wrote:
>> On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
>>> On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
>>>> On 10/09/2015 11:24 PM, Jam
head.S and unwind_frame() structure
for a few of symbols in *.S, so this hunk does not take care of the case.
Cc: AKASHI Takahiro <takahiro.aka...@linaro.org>
Cc: James Morse <james.mo...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Jungseok Lee <jungseokle...
On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
> On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
>> On 10/09/2015 11:24 PM, James Morse wrote:
>>> Hi Jungseok,
>>>
>>> On 07/10/15 16:28, Jungseok Lee wrote:
>>>> Currently, a call trac
On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
> On 10/09/2015 11:24 PM, James Morse wrote:
>> Hi Jungseok,
>>
>> On 07/10/15 16:28, Jungseok Lee wrote:
>>> Currently, a call trace drops a process stack walk when a separate IRQ
>>> stack is used. It m
On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote:
> On Oct 13, 2015, at 8:00 PM, James Morse wrote:
>> Hi Jungseok,
>
> Hi James,
>
>> On 12/10/15 23:13, Jungseok Lee wrote:
>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote:
>>>> Having two kmem_c
On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote:
> On Oct 13, 2015, at 8:00 PM, James Morse wrote:
>> Hi Jungseok,
>
> Hi James,
>
>> On 12/10/15 23:13, Jungseok Lee wrote:
>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote:
>>>> Having two kmem_c
On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
> On 10/09/2015 11:24 PM, James Morse wrote:
>> Hi Jungseok,
>>
>> On 07/10/15 16:28, Jungseok Lee wrote:
>>> Currently, a call trace drops a process stack walk when a separate IRQ
>>> stack is used. It m
On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
> On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
>> On 10/09/2015 11:24 PM, James Morse wrote:
>>> Hi Jungseok,
>>>
>>> On 07/10/15 16:28, Jungseok Lee wrote:
>>>> Currently, a call trac
rm64/kernel/stacktrace.c
index 407991b..7126d4d 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -17,6 +17,7 @@
*/
#include
#include
+#include
#include
#include
----8<
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "
if (*p == (stack_dump_trace[i]
> + + FTRACE_STACK_FRAME_OFFSET)) {
> stack_dump_trace[x] = stack_dump_trace[i++];
> this_size = stack_dump_index[x++] =
> (
On Oct 13, 2015, at 8:00 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 12/10/15 23:13, Jungseok Lee wrote:
>> On Oct 13, 2015, at 1:34 AM, James Morse wrote:
>>> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful
>>> (especi
[i]) {
> + if (*p == (stack_dump_trace[i]
> + + FTRACE_STACK_FRAME_OFFSET)) {
> stack_dump_trace[x] = stack_dump_trace[i++];
> this_size = stack_dump_index[x++] =
>
m64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 407991b..7126d4d 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -17,6 +17,7 @@
*/
#include
#include
+#include
#include
#include
----8<
Best Regards
Jungseok Lee
--
To unsubscribe fro
On Oct 13, 2015, at 8:00 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 12/10/15 23:13, Jungseok Lee wrote:
>> On Oct 13, 2015, at 1:34 AM, James Morse wrote:
>>> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful
>>> (especi
On Oct 13, 2015, at 1:34 AM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 12/10/15 15:53, Jungseok Lee wrote:
>> On Oct 9, 2015, at 11:24 PM, James Morse wrote:
>>> I think unwind_frame() needs to walk the irq stack too. [2] is an example
>>> of
On Oct 9, 2015, at 11:24 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 07/10/15 16:28, Jungseok Lee wrote:
>> Currently, a call trace drops a process stack walk when a separate IRQ
>> stack is used. It makes a call trace information much less useful when
>&g
On Oct 9, 2015, at 11:24 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 07/10/15 16:28, Jungseok Lee wrote:
>> Currently, a call trace drops a process stack walk when a separate IRQ
>> stack is used. It makes a call trace information much less useful when
>&g
On Oct 13, 2015, at 1:34 AM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 12/10/15 15:53, Jungseok Lee wrote:
>> On Oct 9, 2015, at 11:24 PM, James Morse wrote:
>>> I think unwind_frame() needs to walk the irq stack too. [2] is an example
>>> of
1 - 100 of 406 matches
Mail list logo
