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]
Date:	Mon, 06 Oct 2008 18:52:39 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>, mingo@...e.hu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ftrace: Add a C-state tracer to help power
	optimization

On Sat, 2008-10-04 at 11:29 -0700, Arjan van de Ven wrote:

> @@ -100,6 +101,9 @@ static inline int hlt_use_halt(void)
>  void default_idle(void)
>  {
>  	if (hlt_use_halt()) {
> +		struct cstate_trace it;
> +
> +		trace_cstate_start(&it, 1);
>  		current_thread_info()->status &= ~TS_POLLING;
>  		/*
>  		 * TS_POLLING-cleared state must be visible before we
> @@ -112,6 +116,7 @@ void default_idle(void)
>  		else
>  			local_irq_enable();
>  		current_thread_info()->status |= TS_POLLING;
> +		trace_cstate_end(&it);
>  	} else {
>  		local_irq_enable();
>  		/* loop is done by the caller */

> @@ -232,6 +232,20 @@ static inline void start_boot_trace(void) { }
>  static inline void stop_boot_trace(void) { }
>  #endif
>  
> +struct cstate_trace {
> +	ktime_t			stamp;
> +	ktime_t			end;
> +	int			state;
> +};
> +
> +#ifdef CONFIG_CSTATE_TRACER
> +extern void trace_cstate_start(struct cstate_trace *it, unsigned int state);
> +extern void trace_cstate_end(struct cstate_trace *it);
> +#else
> +static inline void trace_cstate_start(struct cstate_trace *it, int state) { }
> +static inline void trace_cstate_end(struct cstate_trace *it) { }
> +#endif
> +
>  
> 
>  #endif /* _LINUX_FTRACE_H */

Why have the cstate_trace structure? If you just log start, stop you
could compute the time delta from the trace time stamps, no?

If you decide to keep the structure, perhaps declare it empty for !
CONFIG_CSTATE_TRACER so as to not bloat stack usage when its not
configured.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ