linux-kernel - Re: [RFC 1/2] cpuidle: trace state of the CPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y5faszax.fsf@sejong.aot.lge.com>
Date:	Thu, 31 Jan 2013 14:21:10 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, tglx@...utronix.de
Subject: Re: [RFC 1/2] cpuidle: trace state of the CPU

On Wed, 30 Jan 2013 22:19:16 +0100, Sebastian Andrzej Siewior wrote:
> This patch adds an interface to cpuidle in order to retrieve the current
> idle state of a given CPU. Zero means the CPU is not in an idle state. Either
> because a cpuidle driver is not available or because the CPU is busy
> executing code. Values greater than zero the CPU indicate that the CPU
> is in some kind of idle state. The larger the value, the deeper the idle
> state.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
>  drivers/cpuidle/cpuidle.c |   13 ++++++++++++-
>  include/linux/cpuidle.h   |    2 ++
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index e1f6860..3594e0c 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -23,6 +23,7 @@
>  #include "cpuidle.h"
>  
>  DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
> +static DEFINE_PER_CPU(unsigned int, cpu_state);

What about making it 'int' as cpuidle_get_state() returns int type?

>  
>  DEFINE_MUTEX(cpuidle_lock);
>  LIST_HEAD(cpuidle_detected_devices);
> @@ -40,13 +41,23 @@ void disable_cpuidle(void)
>  	off = 1;
>  }
>  
> +int cpuidle_get_state(int cpu)
> +{
> +	return per_cpu(cpu_state, cpu);
> +}
> +
>  static int __cpuidle_register_device(struct cpuidle_device *dev);
>  
>  static inline int cpuidle_enter(struct cpuidle_device *dev,
>  				struct cpuidle_driver *drv, int index)
>  {
>  	struct cpuidle_state *target_state = &drv->states[index];
> -	return target_state->enter(dev, drv, index);
> +	int ret;
> +
> +	per_cpu(cpu_state, smp_processor_id()) = index + 1;
> +	ret = target_state->enter(dev, drv, index);
> +	per_cpu(cpu_state, smp_processor_id()) = 0;

Maybe we can use local variable 'cpu' for this duplicated
smp_processor_id() call as it's never executed on another cpu in
between?

Thanks,
Namhyung


> +	return ret;
>  }
>  
>  static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 24cd1037..256baeb 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -155,6 +155,7 @@ extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
>  				struct cpuidle_driver *drv, int index,
>  				int (*enter)(struct cpuidle_device *dev,
>  					struct cpuidle_driver *drv, int index));
> +extern int cpuidle_get_state(int cpu);
>  extern int cpuidle_play_dead(void);
>  
>  extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev);
> @@ -186,6 +187,7 @@ static inline int cpuidle_wrap_enter(struct cpuidle_device *dev,
>  				int (*enter)(struct cpuidle_device *dev,
>  					struct cpuidle_driver *drv, int index))
>  { return -ENODEV; }
> +static inline int cpuidle_get_state(int cpu) {return 0; }
>  static inline int cpuidle_play_dead(void) {return -ENODEV; }
>  #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/