Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Mon, Dec 14, 2015 at 02:02:18PM -0800, Shi, Yang wrote:
> I tried to enable latencytop for arm64 and came across this discussion, so
> any plan about when this will get merged into mainline? 4.5 merge window?

It's queued in linux-next, so I imagine its heading for 4.5.

Will
--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Mon, Dec 14, 2015 at 02:02:18PM -0800, Shi, Yang wrote:
> I tried to enable latencytop for arm64 and came across this discussion, so
> any plan about when this will get merged into mainline? 4.5 merge window?

It's queued in linux-next, so I imagine its heading for 4.5.

Will
--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Shi, Yang]

Hi folks,

I tried to enable latencytop for arm64 and came across this discussion, 
so any plan about when this will get merged into mainline? 4.5 merge window?


Thanks,
Yang


On 11/10/2015 3:34 AM, Heiko Carstens wrote:

From: Will Deacon 
Date: Tue, 10 Nov 2015 11:10:04 +
Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT

As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
implementation of save_stack_trace_tsk.

However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
weak alias") a dummy implementation is provided if STACKTRACE=y.
Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.

Signed-off-by: Will Deacon 
---
  arch/arc/Kconfig| 3 ---
  arch/arm/Kconfig| 5 -
  arch/metag/Kconfig  | 3 ---
  arch/microblaze/Kconfig | 3 ---
  arch/parisc/Kconfig | 3 ---
  arch/powerpc/Kconfig| 3 ---
  arch/s390/Kconfig   | 3 ---
  arch/sh/Kconfig | 3 ---
  arch/sparc/Kconfig  | 4 
  arch/unicore32/Kconfig  | 3 ---
  arch/x86/Kconfig| 3 ---
  lib/Kconfig.debug   | 1 -
  12 files changed, 37 deletions(-)


Acked-by: Heiko Carstens 


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Shi, Yang]

Hi folks,

I tried to enable latencytop for arm64 and came across this discussion, 
so any plan about when this will get merged into mainline? 4.5 merge window?


Thanks,
Yang


On 11/10/2015 3:34 AM, Heiko Carstens wrote:

From: Will Deacon 
Date: Tue, 10 Nov 2015 11:10:04 +
Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT

As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
implementation of save_stack_trace_tsk.

However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
weak alias") a dummy implementation is provided if STACKTRACE=y.
Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.

Signed-off-by: Will Deacon 
---
  arch/arc/Kconfig| 3 ---
  arch/arm/Kconfig| 5 -
  arch/metag/Kconfig  | 3 ---
  arch/microblaze/Kconfig | 3 ---
  arch/parisc/Kconfig | 3 ---
  arch/powerpc/Kconfig| 3 ---
  arch/s390/Kconfig   | 3 ---
  arch/sh/Kconfig | 3 ---
  arch/sparc/Kconfig  | 4 
  arch/unicore32/Kconfig  | 3 ---
  arch/x86/Kconfig| 3 ---
  lib/Kconfig.debug   | 1 -
  12 files changed, 37 deletions(-)


Acked-by: Heiko Carstens 


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

> From: Will Deacon 
> Date: Tue, 10 Nov 2015 11:10:04 +
> Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT
> 
> As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
> HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
> implementation of save_stack_trace_tsk.
> 
> However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
> weak alias") a dummy implementation is provided if STACKTRACE=y.
> Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
> STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.
> 
> Signed-off-by: Will Deacon 
> ---
>  arch/arc/Kconfig| 3 ---
>  arch/arm/Kconfig| 5 -
>  arch/metag/Kconfig  | 3 ---
>  arch/microblaze/Kconfig | 3 ---
>  arch/parisc/Kconfig | 3 ---
>  arch/powerpc/Kconfig| 3 ---
>  arch/s390/Kconfig   | 3 ---
>  arch/sh/Kconfig | 3 ---
>  arch/sparc/Kconfig  | 4 
>  arch/unicore32/Kconfig  | 3 ---
>  arch/x86/Kconfig| 3 ---
>  lib/Kconfig.debug   | 1 -
>  12 files changed, 37 deletions(-)

Acked-by: Heiko Carstens 

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[yalin wang]

> On Nov 10, 2015, at 19:18, Will Deacon  wrote:
> 
> Ha, so it does! Patch below. The only non-trivial part was arch/arm/,
> which has a dependency on !SMP which I believe is no longer required
> as of d5996b2ff0e2 ("ARM: fix /proc/$PID/stack on SMP").
> 
> Will
> 
> --->8
> 
> From 8dfb40e92ac322cbd68bf9f16cbb11fc5e210269 Mon Sep 17 00:00:00 2001
> From: Will Deacon 
> Date: Tue, 10 Nov 2015 11:10:04 +
> Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT
> 
> As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
> HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
> implementation of save_stack_trace_tsk.
> 
> However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
> weak alias") a dummy implementation is provided if STACKTRACE=y.
> Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
> STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.
> 
> Signed-off-by: Will Deacon 
> ---
> arch/arc/Kconfig| 3 ---
> arch/arm/Kconfig| 5 -
> arch/metag/Kconfig  | 3 ---
> arch/microblaze/Kconfig | 3 ---
> arch/parisc/Kconfig | 3 ---
> arch/powerpc/Kconfig| 3 ---
> arch/s390/Kconfig   | 3 ---
> arch/sh/Kconfig | 3 ---
> arch/sparc/Kconfig  | 4 
> arch/unicore32/Kconfig  | 3 ---
> arch/x86/Kconfig| 3 ---
> lib/Kconfig.debug   | 1 -
> 12 files changed, 37 deletions(-)
> 
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 2c2ac3f3ff80..6dc312fd6480 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -73,9 +73,6 @@ config STACKTRACE_SUPPORT
>   def_bool y
>   select STACKTRACE
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config HAVE_ARCH_TRANSPARENT_HUGEPAGE
>   def_bool y
>   depends on ARC_MMU_V4
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 35854e8d97ff..94eff0c6b0f8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -162,11 +162,6 @@ config STACKTRACE_SUPPORT
>   bool
>   default y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - bool
> - depends on !SMP
> - default y
> -
> config LOCKDEP_SUPPORT
>   bool
>   default y
> diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
> index 0b389a81c43a..a0fa88da3e31 100644
> --- a/arch/metag/Kconfig
> +++ b/arch/metag/Kconfig
> @@ -36,9 +36,6 @@ config STACKTRACE_SUPPORT
> config LOCKDEP_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config RWSEM_GENERIC_SPINLOCK
>   def_bool y
> 
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 0bce820428fc..5ecd0287a874 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -67,9 +67,6 @@ config STACKTRACE_SUPPORT
> config LOCKDEP_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> source "init/Kconfig"
> 
> source "kernel/Kconfig.freezer"
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index c36546959e86..16276d505cd6 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -79,9 +79,6 @@ config TIME_LOW_RES
>   depends on SMP
>   default y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> -def_bool y
> -
> # unless you want to implement ACPI on PA-RISC ... ;-)
> config PM
>   bool
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index db49e0d796b1..89210bfdfc7a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -47,9 +47,6 @@ config STACKTRACE_SUPPORT
>   bool
>   default y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config TRACE_IRQFLAGS_SUPPORT
>   bool
>   default y
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 3a55f493c7da..69e22b502d09 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -10,9 +10,6 @@ config LOCKDEP_SUPPORT
> config STACKTRACE_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config RWSEM_GENERIC_SPINLOCK
>   bool
> 
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index d514df7e04dd..6c391a5d3e5c 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -130,9 +130,6 @@ config STACKTRACE_SUPPORT
> config LOCKDEP_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config ARCH_HAS_ILOG2_U32
>   def_bool n
> 
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 56442d2d7bbc..3203e42190dd 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -101,10 +101,6 @@ config LOCKDEP_SUPPORT
>   bool
>   default y if SPARC64
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - bool
> - default y if SPARC64
> -
> config ARCH_HIBERNATION_POSSIBLE
>   def_bool y if SPARC64
> 
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index c9faddc61100..910ed969 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -33,9 +33,6 @@ config NO_IOPORT_MAP
> config STACKTRACE_SUPPORT
>   def_bool y
> 

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Tue, Nov 10, 2015 at 12:01:45PM +0100, Heiko Carstens wrote:
> On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote:
> > Hi Heiko,
> > 
> > On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> > > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > > > > i just enable it on ARM64,
> > > > > and it can work,
> > > > > i don’t see some special requirement to enable this config .
> > > > 
> > > > Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
> [...]
> > > And looking through the kernel there is at least avr32 which would break
> > > at build time if the config option would be removed completely.
> > > 
> > > So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.
> > 
> > ftrace has a similar issue and solves it by having architectures define
> > a `config STACKTRACE_SUPPORT' symbol. Over in kernel/trace/Kconfig,
> > there's a `select STACKTRACE if STACKTRACE_SUPPORT', which means
> > that kernel/stacktrace.c gets built and a dummy (weak symbol) version of
> > save_stack_trace_tsk appears.
> 
> Ah, I wasn't aware of the weak symbol.
> 
> > I don't think adding another STACKTRACE-related Kconfig option is
> > necessarily the best thing to do. Maybe we should instead have LATENCYTOP
> > depend on STACKTRACE_SUPPORT (already the case) and select STACKTRACE?
> 
> LATENCYTOP also already selects STACKTRACE. So it looks like
> HAVE_LATENCYTOP_SUPPORT could simply be removed.

Ha, so it does! Patch below. The only non-trivial part was arch/arm/,
which has a dependency on !SMP which I believe is no longer required
as of d5996b2ff0e2 ("ARM: fix /proc/$PID/stack on SMP").

Will

--->8

>From 8dfb40e92ac322cbd68bf9f16cbb11fc5e210269 Mon Sep 17 00:00:00 2001
From: Will Deacon 
Date: Tue, 10 Nov 2015 11:10:04 +
Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT

As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
implementation of save_stack_trace_tsk.

However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
weak alias") a dummy implementation is provided if STACKTRACE=y.
Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.

Signed-off-by: Will Deacon 
---
 arch/arc/Kconfig| 3 ---
 arch/arm/Kconfig| 5 -
 arch/metag/Kconfig  | 3 ---
 arch/microblaze/Kconfig | 3 ---
 arch/parisc/Kconfig | 3 ---
 arch/powerpc/Kconfig| 3 ---
 arch/s390/Kconfig   | 3 ---
 arch/sh/Kconfig | 3 ---
 arch/sparc/Kconfig  | 4 
 arch/unicore32/Kconfig  | 3 ---
 arch/x86/Kconfig| 3 ---
 lib/Kconfig.debug   | 1 -
 12 files changed, 37 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 2c2ac3f3ff80..6dc312fd6480 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -73,9 +73,6 @@ config STACKTRACE_SUPPORT
def_bool y
select STACKTRACE
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
def_bool y
depends on ARC_MMU_V4
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 35854e8d97ff..94eff0c6b0f8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -162,11 +162,6 @@ config STACKTRACE_SUPPORT
bool
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-   bool
-   depends on !SMP
-   default y
-
 config LOCKDEP_SUPPORT
bool
default y
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 0b389a81c43a..a0fa88da3e31 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -36,9 +36,6 @@ config STACKTRACE_SUPPORT
 config LOCKDEP_SUPPORT
def_bool y
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 config RWSEM_GENERIC_SPINLOCK
def_bool y
 
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 0bce820428fc..5ecd0287a874 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -67,9 +67,6 @@ config STACKTRACE_SUPPORT
 config LOCKDEP_SUPPORT
def_bool y
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index c36546959e86..16276d505cd6 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -79,9 +79,6 @@ config TIME_LOW_RES
depends on SMP
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-def_bool y
-
 # unless you want to implement ACPI on PA-RISC ... ;-)
 config PM
bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index db49e0d796b1..89210bfdfc7a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -47,9 +47,6 @@ config STACKTRACE_SUPPORT
bool
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 config TRACE_IRQFLAGS_SUPPORT
bool
default y
diff --git a/arch/s390/Kconfig 

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote:
> Hi Heiko,
> 
> On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > > > i just enable it on ARM64,
> > > > and it can work,
> > > > i don’t see some special requirement to enable this config .
> > > 
> > > Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
[...]
> > And looking through the kernel there is at least avr32 which would break
> > at build time if the config option would be removed completely.
> > 
> > So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.
> 
> ftrace has a similar issue and solves it by having architectures define
> a `config STACKTRACE_SUPPORT' symbol. Over in kernel/trace/Kconfig,
> there's a `select STACKTRACE if STACKTRACE_SUPPORT', which means
> that kernel/stacktrace.c gets built and a dummy (weak symbol) version of
> save_stack_trace_tsk appears.

Ah, I wasn't aware of the weak symbol.

> I don't think adding another STACKTRACE-related Kconfig option is
> necessarily the best thing to do. Maybe we should instead have LATENCYTOP
> depend on STACKTRACE_SUPPORT (already the case) and select STACKTRACE?

LATENCYTOP also already selects STACKTRACE. So it looks like
HAVE_LATENCYTOP_SUPPORT could simply be removed.

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

Hi Heiko,

On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > > i just enable it on ARM64,
> > > and it can work,
> > > i don’t see some special requirement to enable this config .
> > 
> > Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
> 
> If I remember correctly then the only dependency was that an architecture
> must have implemented save_stack_trace_tsk().
> See git commit a3afe70b83fdbbd4d757d2911900d168bc798a31.

Thanks for the pointer.

> So the name of HAVE_LATENCYTOP_SUPPORT is surely a not well chosen, and I
> think I introduced it back then. Oh, well.
> 
> And looking through the kernel there is at least avr32 which would break
> at build time if the config option would be removed completely.
> 
> So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.

ftrace has a similar issue and solves it by having architectures define
a `config STACKTRACE_SUPPORT' symbol. Over in kernel/trace/Kconfig,
there's a `select STACKTRACE if STACKTRACE_SUPPORT', which means
that kernel/stacktrace.c gets built and a dummy (weak symbol) version of
save_stack_trace_tsk appears.

I don't think adding another STACKTRACE-related Kconfig option is
necessarily the best thing to do. Maybe we should instead have LATENCYTOP
depend on STACKTRACE_SUPPORT (already the case) and select STACKTRACE?

Will
--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

Hi Heiko,

On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > > i just enable it on ARM64,
> > > and it can work,
> > > i don’t see some special requirement to enable this config .
> > 
> > Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
> 
> If I remember correctly then the only dependency was that an architecture
> must have implemented save_stack_trace_tsk().
> See git commit a3afe70b83fdbbd4d757d2911900d168bc798a31.

Thanks for the pointer.

> So the name of HAVE_LATENCYTOP_SUPPORT is surely a not well chosen, and I
> think I introduced it back then. Oh, well.
> 
> And looking through the kernel there is at least avr32 which would break
> at build time if the config option would be removed completely.
> 
> So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.

ftrace has a similar issue and solves it by having architectures define
a `config STACKTRACE_SUPPORT' symbol. Over in kernel/trace/Kconfig,
there's a `select STACKTRACE if STACKTRACE_SUPPORT', which means
that kernel/stacktrace.c gets built and a dummy (weak symbol) version of
save_stack_trace_tsk appears.

I don't think adding another STACKTRACE-related Kconfig option is
necessarily the best thing to do. Maybe we should instead have LATENCYTOP
depend on STACKTRACE_SUPPORT (already the case) and select STACKTRACE?

Will
--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Tue, Nov 10, 2015 at 12:01:45PM +0100, Heiko Carstens wrote:
> On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote:
> > Hi Heiko,
> > 
> > On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> > > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > > > > i just enable it on ARM64,
> > > > > and it can work,
> > > > > i don’t see some special requirement to enable this config .
> > > > 
> > > > Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
> [...]
> > > And looking through the kernel there is at least avr32 which would break
> > > at build time if the config option would be removed completely.
> > > 
> > > So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.
> > 
> > ftrace has a similar issue and solves it by having architectures define
> > a `config STACKTRACE_SUPPORT' symbol. Over in kernel/trace/Kconfig,
> > there's a `select STACKTRACE if STACKTRACE_SUPPORT', which means
> > that kernel/stacktrace.c gets built and a dummy (weak symbol) version of
> > save_stack_trace_tsk appears.
> 
> Ah, I wasn't aware of the weak symbol.
> 
> > I don't think adding another STACKTRACE-related Kconfig option is
> > necessarily the best thing to do. Maybe we should instead have LATENCYTOP
> > depend on STACKTRACE_SUPPORT (already the case) and select STACKTRACE?
> 
> LATENCYTOP also already selects STACKTRACE. So it looks like
> HAVE_LATENCYTOP_SUPPORT could simply be removed.

Ha, so it does! Patch below. The only non-trivial part was arch/arm/,
which has a dependency on !SMP which I believe is no longer required
as of d5996b2ff0e2 ("ARM: fix /proc/$PID/stack on SMP").

Will

--->8

>From 8dfb40e92ac322cbd68bf9f16cbb11fc5e210269 Mon Sep 17 00:00:00 2001
From: Will Deacon 
Date: Tue, 10 Nov 2015 11:10:04 +
Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT

As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
implementation of save_stack_trace_tsk.

However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
weak alias") a dummy implementation is provided if STACKTRACE=y.
Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.

Signed-off-by: Will Deacon 
---
 arch/arc/Kconfig| 3 ---
 arch/arm/Kconfig| 5 -
 arch/metag/Kconfig  | 3 ---
 arch/microblaze/Kconfig | 3 ---
 arch/parisc/Kconfig | 3 ---
 arch/powerpc/Kconfig| 3 ---
 arch/s390/Kconfig   | 3 ---
 arch/sh/Kconfig | 3 ---
 arch/sparc/Kconfig  | 4 
 arch/unicore32/Kconfig  | 3 ---
 arch/x86/Kconfig| 3 ---
 lib/Kconfig.debug   | 1 -
 12 files changed, 37 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 2c2ac3f3ff80..6dc312fd6480 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -73,9 +73,6 @@ config STACKTRACE_SUPPORT
def_bool y
select STACKTRACE
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
def_bool y
depends on ARC_MMU_V4
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 35854e8d97ff..94eff0c6b0f8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -162,11 +162,6 @@ config STACKTRACE_SUPPORT
bool
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-   bool
-   depends on !SMP
-   default y
-
 config LOCKDEP_SUPPORT
bool
default y
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index 0b389a81c43a..a0fa88da3e31 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -36,9 +36,6 @@ config STACKTRACE_SUPPORT
 config LOCKDEP_SUPPORT
def_bool y
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 config RWSEM_GENERIC_SPINLOCK
def_bool y
 
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 0bce820428fc..5ecd0287a874 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -67,9 +67,6 @@ config STACKTRACE_SUPPORT
 config LOCKDEP_SUPPORT
def_bool y
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index c36546959e86..16276d505cd6 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -79,9 +79,6 @@ config TIME_LOW_RES
depends on SMP
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-def_bool y
-
 # unless you want to implement ACPI on PA-RISC ... ;-)
 config PM
bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index db49e0d796b1..89210bfdfc7a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -47,9 +47,6 @@ config STACKTRACE_SUPPORT
bool
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-   def_bool y
-
 config TRACE_IRQFLAGS_SUPPORT
bool
default y
diff 

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[yalin wang]

> On Nov 10, 2015, at 19:18, Will Deacon  wrote:
> 
> Ha, so it does! Patch below. The only non-trivial part was arch/arm/,
> which has a dependency on !SMP which I believe is no longer required
> as of d5996b2ff0e2 ("ARM: fix /proc/$PID/stack on SMP").
> 
> Will
> 
> --->8
> 
> From 8dfb40e92ac322cbd68bf9f16cbb11fc5e210269 Mon Sep 17 00:00:00 2001
> From: Will Deacon 
> Date: Tue, 10 Nov 2015 11:10:04 +
> Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT
> 
> As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
> HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
> implementation of save_stack_trace_tsk.
> 
> However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
> weak alias") a dummy implementation is provided if STACKTRACE=y.
> Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
> STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.
> 
> Signed-off-by: Will Deacon 
> ---
> arch/arc/Kconfig| 3 ---
> arch/arm/Kconfig| 5 -
> arch/metag/Kconfig  | 3 ---
> arch/microblaze/Kconfig | 3 ---
> arch/parisc/Kconfig | 3 ---
> arch/powerpc/Kconfig| 3 ---
> arch/s390/Kconfig   | 3 ---
> arch/sh/Kconfig | 3 ---
> arch/sparc/Kconfig  | 4 
> arch/unicore32/Kconfig  | 3 ---
> arch/x86/Kconfig| 3 ---
> lib/Kconfig.debug   | 1 -
> 12 files changed, 37 deletions(-)
> 
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 2c2ac3f3ff80..6dc312fd6480 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -73,9 +73,6 @@ config STACKTRACE_SUPPORT
>   def_bool y
>   select STACKTRACE
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config HAVE_ARCH_TRANSPARENT_HUGEPAGE
>   def_bool y
>   depends on ARC_MMU_V4
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 35854e8d97ff..94eff0c6b0f8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -162,11 +162,6 @@ config STACKTRACE_SUPPORT
>   bool
>   default y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - bool
> - depends on !SMP
> - default y
> -
> config LOCKDEP_SUPPORT
>   bool
>   default y
> diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
> index 0b389a81c43a..a0fa88da3e31 100644
> --- a/arch/metag/Kconfig
> +++ b/arch/metag/Kconfig
> @@ -36,9 +36,6 @@ config STACKTRACE_SUPPORT
> config LOCKDEP_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config RWSEM_GENERIC_SPINLOCK
>   def_bool y
> 
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 0bce820428fc..5ecd0287a874 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -67,9 +67,6 @@ config STACKTRACE_SUPPORT
> config LOCKDEP_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> source "init/Kconfig"
> 
> source "kernel/Kconfig.freezer"
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index c36546959e86..16276d505cd6 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -79,9 +79,6 @@ config TIME_LOW_RES
>   depends on SMP
>   default y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> -def_bool y
> -
> # unless you want to implement ACPI on PA-RISC ... ;-)
> config PM
>   bool
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index db49e0d796b1..89210bfdfc7a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -47,9 +47,6 @@ config STACKTRACE_SUPPORT
>   bool
>   default y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config TRACE_IRQFLAGS_SUPPORT
>   bool
>   default y
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 3a55f493c7da..69e22b502d09 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -10,9 +10,6 @@ config LOCKDEP_SUPPORT
> config STACKTRACE_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config RWSEM_GENERIC_SPINLOCK
>   bool
> 
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index d514df7e04dd..6c391a5d3e5c 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -130,9 +130,6 @@ config STACKTRACE_SUPPORT
> config LOCKDEP_SUPPORT
>   def_bool y
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - def_bool y
> -
> config ARCH_HAS_ILOG2_U32
>   def_bool n
> 
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 56442d2d7bbc..3203e42190dd 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -101,10 +101,6 @@ config LOCKDEP_SUPPORT
>   bool
>   default y if SPARC64
> 
> -config HAVE_LATENCYTOP_SUPPORT
> - bool
> - default y if SPARC64
> -
> config ARCH_HIBERNATION_POSSIBLE
>   def_bool y if SPARC64
> 
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index c9faddc61100..910ed969 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -33,9 +33,6 @@ config 

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

> From: Will Deacon 
> Date: Tue, 10 Nov 2015 11:10:04 +
> Subject: [PATCH] Kconfig: remove HAVE_LATENCYTOP_SUPPORT
> 
> As illustrated by a3afe70b83fd ("[S390] latencytop s390 support."),
> HAVE_LATENCYTOP_SUPPORT is defined by an architecture to advertise an
> implementation of save_stack_trace_tsk.
> 
> However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
> weak alias") a dummy implementation is provided if STACKTRACE=y.
> Given that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
> STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.
> 
> Signed-off-by: Will Deacon 
> ---
>  arch/arc/Kconfig| 3 ---
>  arch/arm/Kconfig| 5 -
>  arch/metag/Kconfig  | 3 ---
>  arch/microblaze/Kconfig | 3 ---
>  arch/parisc/Kconfig | 3 ---
>  arch/powerpc/Kconfig| 3 ---
>  arch/s390/Kconfig   | 3 ---
>  arch/sh/Kconfig | 3 ---
>  arch/sparc/Kconfig  | 4 
>  arch/unicore32/Kconfig  | 3 ---
>  arch/x86/Kconfig| 3 ---
>  lib/Kconfig.debug   | 1 -
>  12 files changed, 37 deletions(-)

Acked-by: Heiko Carstens 

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote:
> Hi Heiko,
> 
> On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > > > i just enable it on ARM64,
> > > > and it can work,
> > > > i don’t see some special requirement to enable this config .
> > > 
> > > Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
[...]
> > And looking through the kernel there is at least avr32 which would break
> > at build time if the config option would be removed completely.
> > 
> > So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.
> 
> ftrace has a similar issue and solves it by having architectures define
> a `config STACKTRACE_SUPPORT' symbol. Over in kernel/trace/Kconfig,
> there's a `select STACKTRACE if STACKTRACE_SUPPORT', which means
> that kernel/stacktrace.c gets built and a dummy (weak symbol) version of
> save_stack_trace_tsk appears.

Ah, I wasn't aware of the weak symbol.

> I don't think adding another STACKTRACE-related Kconfig option is
> necessarily the best thing to do. Maybe we should instead have LATENCYTOP
> depend on STACKTRACE_SUPPORT (already the case) and select STACKTRACE?

LATENCYTOP also already selects STACKTRACE. So it looks like
HAVE_LATENCYTOP_SUPPORT could simply be removed.

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > i just enable it on ARM64,
> > and it can work,
> > i don’t see some special requirement to enable this config .
> 
> Right, so why does HAVE_LATENCYTOP_SUPPORT exist?

If I remember correctly then the only dependency was that an architecture
must have implemented save_stack_trace_tsk().
See git commit a3afe70b83fdbbd4d757d2911900d168bc798a31.

So the name of HAVE_LATENCYTOP_SUPPORT is surely a not well chosen, and I
think I introduced it back then. Oh, well.

And looking through the kernel there is at least avr32 which would break
at build time if the config option would be removed completely.

So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.

Will do when time permits, unless somebody else volunteers.

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > i just enable it on ARM64,
> > and it can work,
> > i don’t see some special requirement to enable this config .
> 
> Right, so why does HAVE_LATENCYTOP_SUPPORT exist?

If I remember correctly then the only dependency was that an architecture
must have implemented save_stack_trace_tsk().
See git commit a3afe70b83fdbbd4d757d2911900d168bc798a31.

So the name of HAVE_LATENCYTOP_SUPPORT is surely a not well chosen, and I
think I introduced it back then. Oh, well.

And looking through the kernel there is at least avr32 which would break
at build time if the config option would be removed completely.

So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.

Will do when time permits, unless somebody else volunteers.

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> i just enable it on ARM64,
> and it can work,
> i don’t see some special requirement to enable this config .

Right, so why does HAVE_LATENCYTOP_SUPPORT exist?

Will
--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[yalin wang]

i just enable it on ARM64,
and it can work,
i don’t see some special requirement to enable this config .
> On Nov 7, 2015, at 00:05, Will Deacon  wrote:
> 
> On Fri, Nov 06, 2015 at 11:57:58PM +0800, yalin wang wrote:
>> Add HAVE_LATENCYTOP_SUPPORT in Kconfig, so that
>> we can enable this feature on ARM64
> 
> Do you know what the prerequisites for HAVE_LATENCYTOP_SUPPORT actually
> are (beyond those explicitly listed as dependencies for CONFIG_LATENCYTOP)?
> 
> Will

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Fri, Nov 06, 2015 at 11:57:58PM +0800, yalin wang wrote:
> Add HAVE_LATENCYTOP_SUPPORT in Kconfig, so that
> we can enable this feature on ARM64

Do you know what the prerequisites for HAVE_LATENCYTOP_SUPPORT actually
are (beyond those explicitly listed as dependencies for CONFIG_LATENCYTOP)?

Will
--
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/

[PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[yalin wang]

Add HAVE_LATENCYTOP_SUPPORT in Kconfig, so that
we can enable this feature on ARM64

Signed-off-by: yalin wang 
---
 arch/arm64/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 851fe11..782b5bd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -103,6 +103,10 @@ config ARCH_PHYS_ADDR_T_64BIT
 config MMU
def_bool y
 
+config HAVE_LATENCYTOP_SUPPORT
+   bool
+   default y
+
 config NO_IOPORT_MAP
def_bool y if !PCI
 
-- 
1.9.1

--
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/

[PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[yalin wang]

Add HAVE_LATENCYTOP_SUPPORT in Kconfig, so that
we can enable this feature on ARM64

Signed-off-by: yalin wang 
---
 arch/arm64/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 851fe11..782b5bd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -103,6 +103,10 @@ config ARCH_PHYS_ADDR_T_64BIT
 config MMU
def_bool y
 
+config HAVE_LATENCYTOP_SUPPORT
+   bool
+   default y
+
 config NO_IOPORT_MAP
def_bool y if !PCI
 
-- 
1.9.1

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Fri, Nov 06, 2015 at 11:57:58PM +0800, yalin wang wrote:
> Add HAVE_LATENCYTOP_SUPPORT in Kconfig, so that
> we can enable this feature on ARM64

Do you know what the prerequisites for HAVE_LATENCYTOP_SUPPORT actually
are (beyond those explicitly listed as dependencies for CONFIG_LATENCYTOP)?

Will
--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[yalin wang]

i just enable it on ARM64,
and it can work,
i don’t see some special requirement to enable this config .
> On Nov 7, 2015, at 00:05, Will Deacon  wrote:
> 
> On Fri, Nov 06, 2015 at 11:57:58PM +0800, yalin wang wrote:
>> Add HAVE_LATENCYTOP_SUPPORT in Kconfig, so that
>> we can enable this feature on ARM64
> 
> Do you know what the prerequisites for HAVE_LATENCYTOP_SUPPORT actually
> are (beyond those explicitly listed as dependencies for CONFIG_LATENCYTOP)?
> 
> Will

--
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/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Will Deacon]

On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> i just enable it on ARM64,
> and it can work,
> i don’t see some special requirement to enable this config .

Right, so why does HAVE_LATENCYTOP_SUPPORT exist?

Will
--
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/