linux-kernel - Re: [PATCH V4 3/4] block: queue work on unbound wq

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: <20130409183020.GD6186@mtj.dyndns.org>
Date:	Tue, 9 Apr 2013 11:30:20 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	robin.randhawa@....com, Steve.Bannister@....com,
	Liviu.Dudau@....com, charles.garcia-tobin@....com,
	arvind.chauhan@....com, davem@...emloft.net, airlied@...hat.com,
	axboe@...nel.dk, tglx@...utronix.de, peterz@...radead.org,
	mingo@...hat.com, rostedt@...dmis.org,
	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4 3/4] block: queue work on unbound wq

Yo!

On Tue, Apr 09, 2013 at 01:00:59PM +0530, Viresh Kumar wrote:
> +	workqueue.power_efficient
> +			Workqueues can be performance or power oriented. For
> +			performance we may want to keep them running on a single
> +			cpu, so that it remains cache hot. For power we can give
> +			scheduler the liberty to choose target cpu for running
> +			work handler.
> +
> +			Later one (Power oriented WQ) can be achieved if the
> +			workqueue is allocated with WQ_UNBOUND flag. Enabling
> +			power_efficient boot param will convert
> +			WQ_POWER_EFFICIENT flag to WQ_UNBOUND on wq allocation.
> +			This requires CONFIG_WQ_POWER_EFFICIENT to be enabled.
> +			WQ_POWER_EFFICIENT is unused if power_efficient is not
> +			set in boot params.

Looks mostly good to me but I think it'd be better if the parameter
name is a bit more specific.

> @@ -299,6 +299,9 @@ enum {
>  	WQ_HIGHPRI		= 1 << 4, /* high priority */
>  	WQ_CPU_INTENSIVE	= 1 << 5, /* cpu instensive workqueue */
>  	WQ_SYSFS		= 1 << 6, /* visible in sysfs, see wq_sysfs_register() */
> +	WQ_POWER_EFFICIENT	= 1 << 7, /* WQ_UNBOUND, for power
> +					   * saving, if wq_power_efficient is
> +					   * enabled. Unused otherwise. */

Ditto for the flag name.  It's not a requirement tho.  If you can
think of something which is a bit more specific to what it does while
not being unreasonably long, great.  If not, we'll live.

> @@ -271,6 +271,11 @@ static cpumask_var_t *wq_numa_possible_cpumask;
>  static bool wq_disable_numa;
>  module_param_named(disable_numa, wq_disable_numa, bool, 0444);
> 
> +#ifdef CONFIG_WQ_POWER_EFFICIENT
> +static bool wq_power_efficient = 0;
> +module_param_named(power_efficient, wq_power_efficient, bool, 0444);
> +#endif

I don't think we need to make the whole thing configurable.  Turning
it off isn't gonna save much - my gut tells me it's gonna be four
instructions. :)

What I meant was that the default value for the parameter would
probably be need to be configurable so that mobile people don't have
to include the kernel param all the time or patch the kernel
themselves.

> +	if (flags & WQ_POWER_EFFICIENT) {
> +		flags &= ~WQ_POWER_EFFICIENT;

No need to clear the flag.

> +#ifdef CONFIG_WQ_POWER_EFFICIENT
> +		if (wq_power_efficient)
> +			flags |= WQ_UNBOUND;
> +#endif

Thanks!

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