linux-kernel - Re: [PATCH 2/2] [RFC] spi/bitbang: Use a kthread worker instead of workqueue

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>] [day] [month] [year] [list]
Date:	Tue, 15 Feb 2011 21:26:31 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	spi-devel-general@...ts.sourceforge.net,
	Sascha Hauer <s.hauer@...gutronix.de>, kernel@...gutronix.de,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] [RFC] spi/bitbang: Use a kthread worker instead of
 workqueue

On Tue, Feb 08, 2011 at 10:46:15AM +0100, Uwe Kleine-König wrote:
> From: Sascha Hauer <s.hauer@...gutronix.de>
> 
> Since the concurrency managed workqueues are merged we often have
> several microseconds delays in spi transfers. This patch resolves
> this by using a kthread worker in spi_bitbang instead.
> 
> Signed-off-by: Sascha Hauer <s.hauer@...gutronix.de>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>

Hmmm, I could use some input here from folks with a better
understanding of the concurrency managed workqueues.  Is switching to
a kthread worker the right thing to do, or is it working around a bug
in the workqueue implementation that should be fixed instead?

Anyone care to chime in?

g.

> ---
>  drivers/spi/spi_bitbang.c       |   17 ++++++++++-------
>  include/linux/spi/spi_bitbang.h |    7 ++++---
>  2 files changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/spi/spi_bitbang.c b/drivers/spi/spi_bitbang.c
> index 14a63f6..e2a874a 100644
> --- a/drivers/spi/spi_bitbang.c
> +++ b/drivers/spi/spi_bitbang.c
> @@ -254,7 +254,7 @@ static int spi_bitbang_bufs(struct spi_device *spi, struct spi_transfer *t)
>   * Drivers can provide word-at-a-time i/o primitives, or provide
>   * transfer-at-a-time ones to leverage dma or fifo hardware.
>   */
> -static void bitbang_work(struct work_struct *work)
> +static void bitbang_work(struct kthread_work *work)
>  {
>  	struct spi_bitbang	*bitbang =
>  		container_of(work, struct spi_bitbang, work);
> @@ -396,7 +396,7 @@ int spi_bitbang_transfer(struct spi_device *spi, struct spi_message *m)
>  		status = -ENETDOWN;
>  	else {
>  		list_add_tail(&m->queue, &bitbang->queue);
> -		queue_work(bitbang->workqueue, &bitbang->work);
> +		queue_kthread_work(&bitbang->worker, &bitbang->work);
>  	}
>  	spin_unlock_irqrestore(&bitbang->lock, flags);
>  
> @@ -432,11 +432,12 @@ EXPORT_SYMBOL_GPL(spi_bitbang_transfer);
>  int spi_bitbang_start(struct spi_bitbang *bitbang)
>  {
>  	int	status;
> +	struct sched_param param = { .sched_priority = 49 };
>  
>  	if (!bitbang->master || !bitbang->chipselect)
>  		return -EINVAL;
>  
> -	INIT_WORK(&bitbang->work, bitbang_work);
> +	init_kthread_work(&bitbang->work, bitbang_work);
>  	spin_lock_init(&bitbang->lock);
>  	INIT_LIST_HEAD(&bitbang->queue);
>  
> @@ -463,12 +464,14 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
>  
>  	/* this task is the only thing to touch the SPI bits */
>  	bitbang->busy = 0;
> -	bitbang->workqueue = create_singlethread_workqueue(
> +	init_kthread_worker(&bitbang->worker);
> +	bitbang->worker_task = kthread_run(kthread_worker_fn, &bitbang->worker,
>  			dev_name(bitbang->master->dev.parent));
> -	if (bitbang->workqueue == NULL) {
> +	if (bitbang->worker_task == NULL) {
>  		status = -EBUSY;
>  		goto err1;
>  	}
> +	sched_setscheduler(bitbang->worker_task, SCHED_FIFO, &param);
>  
>  	/* driver may get busy before register() returns, especially
>  	 * if someone registered boardinfo for devices
> @@ -480,7 +483,7 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
>  	return status;
>  
>  err2:
> -	destroy_workqueue(bitbang->workqueue);
> +	kthread_stop(bitbang->worker_task);
>  err1:
>  	return status;
>  }
> @@ -495,7 +498,7 @@ int spi_bitbang_stop(struct spi_bitbang *bitbang)
>  
>  	WARN_ON(!list_empty(&bitbang->queue));
>  
> -	destroy_workqueue(bitbang->workqueue);
> +	kthread_stop(bitbang->worker_task);
>  
>  	return 0;
>  }
> diff --git a/include/linux/spi/spi_bitbang.h b/include/linux/spi/spi_bitbang.h
> index f987a2b..36bb3be 100644
> --- a/include/linux/spi/spi_bitbang.h
> +++ b/include/linux/spi/spi_bitbang.h
> @@ -1,11 +1,12 @@
>  #ifndef	__SPI_BITBANG_H
>  #define	__SPI_BITBANG_H
>  
> -#include <linux/workqueue.h>
> +#include <linux/kthread.h>
>  
>  struct spi_bitbang {
> -	struct workqueue_struct	*workqueue;
> -	struct work_struct	work;
> +	struct kthread_worker	worker;
> +	struct task_struct	*worker_task;
> +	struct kthread_work	work;
>  
>  	spinlock_t		lock;
>  	struct list_head	queue;
> -- 
> 1.7.2.3
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
--
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/