Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-18 Thread Byungchul Park
On Mon, Jul 18, 2016 at 08:09:10AM -0500, Josh Poimboeuf wrote: > > > > There are several different users of save_stack_trace() in the kernel, > > > > we can't > > > > be sure that all of them are interested in dropping those guesses. > > > > > > > > So I'd rather advocate in favour of a new sepe

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-18 Thread Josh Poimboeuf
On Mon, Jul 18, 2016 at 12:14:22PM +0900, Byungchul Park wrote: > On Fri, Jul 08, 2016 at 10:22:46AM -0500, Josh Poimboeuf wrote: > > > > > Also, could you please rename the _norm names to _fast or so, to > > > > > signal that this > > > > > is a faster but less reliable method to get a stack dum

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-17 Thread Byungchul Park
On Fri, Jul 08, 2016 at 04:44:04PM +0200, Frederic Weisbecker wrote: > Nice improvement but how about doing that with the return value of > stacktrace_ops::address() instead? > > print_context_stack_bp() uses that for example. This behaviour could > be extended. Yes. I will leave the change in pr

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-17 Thread Byungchul Park
On Fri, Jul 08, 2016 at 10:22:46AM -0500, Josh Poimboeuf wrote: > > > > Also, could you please rename the _norm names to _fast or so, to signal > > > > that this > > > > is a faster but less reliable method to get a stack dump? Nobody knows > > > > what > > > > '_norm' means, but '_fast' is pre

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-17 Thread Byungchul Park
On Fri, Jul 08, 2016 at 05:02:33PM +0200, Frederic Weisbecker wrote: > On Fri, Jul 08, 2016 at 09:29:29AM -0500, Josh Poimboeuf wrote: > > On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > > > > > * Byungchul Park wrote: > > > > > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byun

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-17 Thread Byungchul Park
On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byungchul Park wrote: > > > I suggested this patch on https://lkml.org/lkml/2016/6/20/22. However, > > > I want to proceed saperately since it's somewhat indep

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Josh Poimboeuf
On Fri, Jul 08, 2016 at 05:02:33PM +0200, Frederic Weisbecker wrote: > On Fri, Jul 08, 2016 at 09:29:29AM -0500, Josh Poimboeuf wrote: > > On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > > > > > * Byungchul Park wrote: > > > > > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byun

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Frederic Weisbecker
On Fri, Jul 08, 2016 at 09:29:29AM -0500, Josh Poimboeuf wrote: > On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > > > * Byungchul Park wrote: > > > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byungchul Park wrote: > > > > I suggested this patch on https://lkml.org/lkml/2016/6/

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Frederic Weisbecker
On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byungchul Park wrote: > > > I suggested this patch on https://lkml.org/lkml/2016/6/20/22. However, > > > I want to proceed saperately since it's somewhat indep

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Ingo Molnar
* Josh Poimboeuf wrote: > On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > > > * Byungchul Park wrote: > > > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byungchul Park wrote: > > > > I suggested this patch on https://lkml.org/lkml/2016/6/20/22. However, > > > > I want to pro

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Frederic Weisbecker
so > that the crossfeature can use this optimized save_stack_trace_norm() > which makes crossrelease work smoothly. > > ->8- > From 1ceb4cee520cfc562d5d63471f6db4e9a8d9ff42 Mon Sep 17 00:00:00 2001 > From: Byungchul Park > Date: Mon, 4 Jul 2016 18:31:09 +0900 > Sub

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Josh Poimboeuf
On Fri, Jul 08, 2016 at 12:08:19PM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byungchul Park wrote: > > > I suggested this patch on https://lkml.org/lkml/2016/6/20/22. However, > > > I want to proceed saperately since it's somewhat indep

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Josh Poimboeuf
so > that the crossfeature can use this optimized save_stack_trace_norm() > which makes crossrelease work smoothly. > > ->8- > From 1ceb4cee520cfc562d5d63471f6db4e9a8d9ff42 Mon Sep 17 00:00:00 2001 > From: Byungchul Park > Date: Mon, 4 Jul 2016 18:31:09 +0900 > Sub

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-08 Thread Ingo Molnar
* Byungchul Park wrote: > On Mon, Jul 04, 2016 at 07:27:54PM +0900, Byungchul Park wrote: > > I suggested this patch on https://lkml.org/lkml/2016/6/20/22. However, > > I want to proceed saperately since it's somewhat independent from each > > other. Frankly speaking, I want this patchset to be

Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-07 Thread Byungchul Park
Park > Date: Mon, 4 Jul 2016 18:31:09 +0900 > Subject: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace > > Currently, x86 implementation of save_stack_trace() is walking all stack > region word by word regardless of what the trace->max_entries is. > However, it's unn

[PATCH 1/2] x86/dumpstack: Optimize save_stack_trace

2016-07-04 Thread Byungchul Park
makes crossrelease work smoothly. ->8- >From 1ceb4cee520cfc562d5d63471f6db4e9a8d9ff42 Mon Sep 17 00:00:00 2001 From: Byungchul Park Date: Mon, 4 Jul 2016 18:31:09 +0900 Subject: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace Currently, x86 implementation of save_stack_trace() is