Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1472750 > unrolled thread

[PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue

Back to article view | Back to linux.kernel

Contents

  [PATCH] ASoC: tlv320dac33: Remove deprecated  create_singlethread_workqueue Bhaktipriya Shridhar <bhaktipriya96@gmail.com> - 2016-08-30 20:30 +0200
    Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated  create_singlethread_workqueue Peter Ujfalusi <peter.ujfalusi@ti.com> - 2016-08-31 14:00 +0200
      Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated  create_singlethread_workqueue Tejun Heo <tj@kernel.org> - 2016-08-31 16:50 +0200
        Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated  create_singlethread_workqueue Peter Ujfalusi <peter.ujfalusi@ti.com> - 2016-08-31 21:20 +0200
          Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated  create_singlethread_workqueue Tejun Heo <tj@kernel.org> - 2016-08-31 23:20 +0200

#1472750 — [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue

The workqueue "dac33_wq" queues a single work item &dac33->work and hence
doesn't require ordering. Also, it is not being used on a memory reclaim
path. Hence, it has been converted to use system_wq.

The work item has been flushed in dac33_soc_remove to ensure that
there are no pending tasks while disconnecting the driver.

The workqueue "post_msg_wq" queues a single work item
&drv->ipc_post_msg_wq and hence doesn't require ordering. Also, it is
not being used on a memory reclaim path. Hence, it has been converted to
use system_wq.

The work item has been flushed in sst_context_cleanup to ensure that
there are no pending tasks while disconnecting the driver.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
---
 sound/soc/codecs/tlv320dac33.c | 17 ++++-------------
 sound/soc/intel/atom/sst/sst.c | 14 +++++---------
 2 files changed, 9 insertions(+), 22 deletions(-)

diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index f7a6ce7..6822ac1 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -90,7 +90,6 @@ static const char *dac33_supply_names[DAC33_NUM_SUPPLIES] = {

 struct tlv320dac33_priv {
 	struct mutex mutex;
-	struct workqueue_struct *dac33_wq;
 	struct work_struct work;
 	struct snd_soc_codec *codec;
 	struct regulator_bulk_data supplies[DAC33_NUM_SUPPLIES];
@@ -771,7 +770,7 @@ static irqreturn_t dac33_interrupt_handler(int irq, void *dev)

 	/* Do not schedule the workqueue in Mode7 */
 	if (dac33->fifo_mode != DAC33_FIFO_MODE7)
-		queue_work(dac33->dac33_wq, &dac33->work);
+		schedule_work(&dac33->work);

 	return IRQ_HANDLED;
 }
@@ -1127,7 +1126,7 @@ static int dac33_pcm_trigger(struct snd_pcm_substream *substream, int cmd,
 	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 		if (dac33->fifo_mode) {
 			dac33->state = DAC33_PREFILL;
-			queue_work(dac33->dac33_wq, &dac33->work);
+			schedule_work(&dac33->work);
 		}
 		break;
 	case SNDRV_PCM_TRIGGER_STOP:
@@ -1135,7 +1134,7 @@ static int dac33_pcm_trigger(struct snd_pcm_substream *substream, int cmd,
 	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
 		if (dac33->fifo_mode) {
 			dac33->state = DAC33_FLUSH;
-			queue_work(dac33->dac33_wq, &dac33->work);
+			schedule_work(&dac33->work);
 		}
 		break;
 	default:
@@ -1410,14 +1409,6 @@ static int dac33_soc_probe(struct snd_soc_codec *codec)
 			dac33->irq = -1;
 		}
 		if (dac33->irq != -1) {
-			/* Setup work queue */
-			dac33->dac33_wq =
-				create_singlethread_workqueue("tlv320dac33");
-			if (dac33->dac33_wq == NULL) {
-				free_irq(dac33->irq, codec);
-				return -ENOMEM;
-			}
-
 			INIT_WORK(&dac33->work, dac33_work);
 		}
 	}
@@ -1437,7 +1428,7 @@ static int dac33_soc_remove(struct snd_soc_codec *codec)

 	if (dac33->irq >= 0) {
 		free_irq(dac33->irq, dac33->codec);
-		destroy_workqueue(dac33->dac33_wq);
+		flush_work(&dac33->work);
 	}
 	return 0;
 }
diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
index a4b458e..8cfd0cf 100644
--- a/sound/soc/intel/atom/sst/sst.c
+++ b/sound/soc/intel/atom/sst/sst.c
@@ -76,7 +76,7 @@ static irqreturn_t intel_sst_interrupt_mrfld(int irq, void *context)
 		spin_unlock(&drv->ipc_spin_lock);

 		/* we can send more messages to DSP so trigger work */
-		queue_work(drv->post_msg_wq, &drv->ipc_post_msg_wq);
+		schedule_work(&drv->ipc_post_msg_wq);
 		retval = IRQ_HANDLED;
 	}

@@ -212,10 +212,6 @@ static int sst_workqueue_init(struct intel_sst_drv *ctx)
 	INIT_WORK(&ctx->ipc_post_msg_wq, sst_process_pending_msg);
 	init_waitqueue_head(&ctx->wait_queue);

-	ctx->post_msg_wq =
-		create_singlethread_workqueue("sst_post_msg_wq");
-	if (!ctx->post_msg_wq)
-		return -EBUSY;
 	return 0;
 }

@@ -318,7 +314,6 @@ int sst_context_init(struct intel_sst_drv *ctx)
 	return 0;

 do_free_mem:
-	destroy_workqueue(ctx->post_msg_wq);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(sst_context_init);
@@ -330,7 +325,7 @@ void sst_context_cleanup(struct intel_sst_drv *ctx)
 	sst_unregister(ctx->dev);
 	sst_set_fw_state_locked(ctx, SST_SHUTDOWN);
 	flush_scheduled_work();
-	destroy_workqueue(ctx->post_msg_wq);
+	flush_work(&ctx->ipc_post_msg_wq);
 	pm_qos_remove_request(ctx->qos);
 	kfree(ctx->fw_sg_list.src);
 	kfree(ctx->fw_sg_list.dst);
@@ -414,7 +409,7 @@ static int intel_sst_runtime_suspend(struct device *dev)
 	sst_set_fw_state_locked(ctx, SST_RESET);

 	synchronize_irq(ctx->irq_num);
-	flush_workqueue(ctx->post_msg_wq);
+	flush_work(&ctx->ipc_post_msg_wq);

 	ctx->ops->reset(ctx);
 	/* save the shim registers because PMC doesn't save state */
@@ -445,8 +440,9 @@ static int intel_sst_suspend(struct device *dev)
 			return -EBUSY;
 		}
 	}
+
 	synchronize_irq(ctx->irq_num);
-	flush_workqueue(ctx->post_msg_wq);
+	flush_work(ctx->ipc_post_msg_wq);

 	/* Move the SST state to Reset */
 	sst_set_fw_state_locked(ctx, SST_RESET);
--
2.1.4

[toc] | [next] | [standalone]

#1473377 — Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue

On 08/30/16 21:27, Bhaktipriya Shridhar wrote:
> The workqueue "dac33_wq" queues a single work item &dac33->work and hence
> doesn't require ordering. Also, it is not being used on a memory reclaim
> path. Hence, it has been converted to use system_wq.
>
> The work item has been flushed in dac33_soc_remove to ensure that
> there are no pending tasks while disconnecting the driver.

The reason why dac33 had it's own wq is that it is absolutely time critical
that the work is not going to be delayed by the scheduling needs with the
system_wq. If the work execution is delayed, we could run out of time in FIFO
mode, which can cause the chip to hang do to FIFO underrun.

Unfortunately I'm no longer able to test the dac33 as I don't have the HW any
more.

If you are 100% percent sure that this is not going to delay the work, then
I'm OK with the change, but I have used the dedicated queue at the time,
because the system_wq given unpredictable latencies.

> The workqueue "post_msg_wq" queues a single work item
> &drv->ipc_post_msg_wq and hence doesn't require ordering. Also, it is
> not being used on a memory reclaim path. Hence, it has been converted to
> use system_wq.
> 
> The work item has been flushed in sst_context_cleanup to ensure that
> there are no pending tasks while disconnecting the driver.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
> ---
>  sound/soc/codecs/tlv320dac33.c | 17 ++++-------------
>  sound/soc/intel/atom/sst/sst.c | 14 +++++---------

two separate patch?

>  2 files changed, 9 insertions(+), 22 deletions(-)
> 
> diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
> index f7a6ce7..6822ac1 100644
> --- a/sound/soc/codecs/tlv320dac33.c
> +++ b/sound/soc/codecs/tlv320dac33.c
> @@ -90,7 +90,6 @@ static const char *dac33_supply_names[DAC33_NUM_SUPPLIES] = {
> 
>  struct tlv320dac33_priv {
>  	struct mutex mutex;
> -	struct workqueue_struct *dac33_wq;
>  	struct work_struct work;
>  	struct snd_soc_codec *codec;
>  	struct regulator_bulk_data supplies[DAC33_NUM_SUPPLIES];
> @@ -771,7 +770,7 @@ static irqreturn_t dac33_interrupt_handler(int irq, void *dev)
> 
>  	/* Do not schedule the workqueue in Mode7 */
>  	if (dac33->fifo_mode != DAC33_FIFO_MODE7)
> -		queue_work(dac33->dac33_wq, &dac33->work);
> +		schedule_work(&dac33->work);
> 
>  	return IRQ_HANDLED;
>  }
> @@ -1127,7 +1126,7 @@ static int dac33_pcm_trigger(struct snd_pcm_substream *substream, int cmd,
>  	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>  		if (dac33->fifo_mode) {
>  			dac33->state = DAC33_PREFILL;
> -			queue_work(dac33->dac33_wq, &dac33->work);
> +			schedule_work(&dac33->work);
>  		}
>  		break;
>  	case SNDRV_PCM_TRIGGER_STOP:
> @@ -1135,7 +1134,7 @@ static int dac33_pcm_trigger(struct snd_pcm_substream *substream, int cmd,
>  	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
>  		if (dac33->fifo_mode) {
>  			dac33->state = DAC33_FLUSH;
> -			queue_work(dac33->dac33_wq, &dac33->work);
> +			schedule_work(&dac33->work);
>  		}
>  		break;
>  	default:
> @@ -1410,14 +1409,6 @@ static int dac33_soc_probe(struct snd_soc_codec *codec)
>  			dac33->irq = -1;
>  		}
>  		if (dac33->irq != -1) {
> -			/* Setup work queue */
> -			dac33->dac33_wq =
> -				create_singlethread_workqueue("tlv320dac33");
> -			if (dac33->dac33_wq == NULL) {
> -				free_irq(dac33->irq, codec);
> -				return -ENOMEM;
> -			}
> -
>  			INIT_WORK(&dac33->work, dac33_work);
>  		}
>  	}
> @@ -1437,7 +1428,7 @@ static int dac33_soc_remove(struct snd_soc_codec *codec)
> 
>  	if (dac33->irq >= 0) {
>  		free_irq(dac33->irq, dac33->codec);
> -		destroy_workqueue(dac33->dac33_wq);
> +		flush_work(&dac33->work);
>  	}
>  	return 0;
>  }
> diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
> index a4b458e..8cfd0cf 100644
> --- a/sound/soc/intel/atom/sst/sst.c
> +++ b/sound/soc/intel/atom/sst/sst.c
> @@ -76,7 +76,7 @@ static irqreturn_t intel_sst_interrupt_mrfld(int irq, void *context)
>  		spin_unlock(&drv->ipc_spin_lock);
> 
>  		/* we can send more messages to DSP so trigger work */
> -		queue_work(drv->post_msg_wq, &drv->ipc_post_msg_wq);
> +		schedule_work(&drv->ipc_post_msg_wq);
>  		retval = IRQ_HANDLED;
>  	}
> 
> @@ -212,10 +212,6 @@ static int sst_workqueue_init(struct intel_sst_drv *ctx)
>  	INIT_WORK(&ctx->ipc_post_msg_wq, sst_process_pending_msg);
>  	init_waitqueue_head(&ctx->wait_queue);
> 
> -	ctx->post_msg_wq =
> -		create_singlethread_workqueue("sst_post_msg_wq");
> -	if (!ctx->post_msg_wq)
> -		return -EBUSY;
>  	return 0;
>  }
> 
> @@ -318,7 +314,6 @@ int sst_context_init(struct intel_sst_drv *ctx)
>  	return 0;
> 
>  do_free_mem:
> -	destroy_workqueue(ctx->post_msg_wq);
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(sst_context_init);
> @@ -330,7 +325,7 @@ void sst_context_cleanup(struct intel_sst_drv *ctx)
>  	sst_unregister(ctx->dev);
>  	sst_set_fw_state_locked(ctx, SST_SHUTDOWN);
>  	flush_scheduled_work();
> -	destroy_workqueue(ctx->post_msg_wq);
> +	flush_work(&ctx->ipc_post_msg_wq);
>  	pm_qos_remove_request(ctx->qos);
>  	kfree(ctx->fw_sg_list.src);
>  	kfree(ctx->fw_sg_list.dst);
> @@ -414,7 +409,7 @@ static int intel_sst_runtime_suspend(struct device *dev)
>  	sst_set_fw_state_locked(ctx, SST_RESET);
> 
>  	synchronize_irq(ctx->irq_num);
> -	flush_workqueue(ctx->post_msg_wq);
> +	flush_work(&ctx->ipc_post_msg_wq);
> 
>  	ctx->ops->reset(ctx);
>  	/* save the shim registers because PMC doesn't save state */
> @@ -445,8 +440,9 @@ static int intel_sst_suspend(struct device *dev)
>  			return -EBUSY;
>  		}
>  	}
> +
>  	synchronize_irq(ctx->irq_num);
> -	flush_workqueue(ctx->post_msg_wq);
> +	flush_work(ctx->ipc_post_msg_wq);
> 
>  	/* Move the SST state to Reset */
>  	sst_set_fw_state_locked(ctx, SST_RESET);
> --
> 2.1.4
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 


-- 
Péter

[toc] | [prev] | [next] | [standalone]

#1473569 — Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue

Hello, Peter.

On Wed, Aug 31, 2016 at 02:56:50PM +0300, Peter Ujfalusi wrote:
> On 08/30/16 21:27, Bhaktipriya Shridhar wrote:
> > The workqueue "dac33_wq" queues a single work item &dac33->work and hence
> > doesn't require ordering. Also, it is not being used on a memory reclaim
> > path. Hence, it has been converted to use system_wq.
> >
> > The work item has been flushed in dac33_soc_remove to ensure that
> > there are no pending tasks while disconnecting the driver.
> 
> The reason why dac33 had it's own wq is that it is absolutely time critical
> that the work is not going to be delayed by the scheduling needs with the
> system_wq. If the work execution is delayed, we could run out of time in FIFO
> mode, which can cause the chip to hang do to FIFO underrun.

In the current implementation of wq, which has been around for many
years now, there's no real timing advantage to using a dedicated
workqueue or rather system_wq doesn't get blocked by other work items
on it.  They are all served by the same backend pools and dedicated
workqueues mostly serve as attribute, flush and mem-reclaim domains.

> Unfortunately I'm no longer able to test the dac33 as I don't have the HW any
> more.
> 
> If you are 100% percent sure that this is not going to delay the work, then
> I'm OK with the change, but I have used the dedicated queue at the time,
> because the system_wq given unpredictable latencies.

What kind of time frame are we talking about?  If it really needs high
priority, the right thing to do would be using a WQ_HIGHPRI workqueue.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1473796 — Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue

On 08/31/16 17:44, Tejun Heo wrote:
> Hello, Peter.
>
> On Wed, Aug 31, 2016 at 02:56:50PM +0300, Peter Ujfalusi wrote:
>> On 08/30/16 21:27, Bhaktipriya Shridhar wrote:
>>> The workqueue "dac33_wq" queues a single work item &dac33->work and hence
>>> doesn't require ordering. Also, it is not being used on a memory reclaim
>>> path. Hence, it has been converted to use system_wq.
>>>
>>> The work item has been flushed in dac33_soc_remove to ensure that
>>> there are no pending tasks while disconnecting the driver.
>>
>> The reason why dac33 had it's own wq is that it is absolutely time critical
>> that the work is not going to be delayed by the scheduling needs with the
>> system_wq. If the work execution is delayed, we could run out of time in FIFO
>> mode, which can cause the chip to hang do to FIFO underrun.
>
> In the current implementation of wq, which has been around for many
> years now, there's no real timing advantage to using a dedicated
> workqueue or rather system_wq doesn't get blocked by other work items
> on it.  They are all served by the same backend pools and dedicated
> workqueues mostly serve as attribute, flush and mem-reclaim domains.

The dac33 driver was productised with 2.6.32 kernel and there the dedicated wq
was needed. I know lots have changed, so it is most likely not the case anymore.

>> Unfortunately I'm no longer able to test the dac33 as I don't have the HW any
>> more.
>>
>> If you are 100% percent sure that this is not going to delay the work, then
>> I'm OK with the change, but I have used the dedicated queue at the time,
>> because the system_wq given unpredictable latencies.
>
> What kind of time frame are we talking about?  If it really needs high
> priority, the right thing to do would be using a WQ_HIGHPRI workqueue.

In order to be tune the performance and power saving during audio playback
lower is better, but consistency matters more to be able have stable system.
I have some latency compensation in the code so it could tolerate some drift,
but big spikes can cause the codec to go underflow and we can not recover from
that w/o hard reset of the codec.

I do believe that Linux got much better over the years since I wrote the dac33
driver, so I'm fine with the move to system_wq. The most problematic mode (I
think it was MODE7LP or smthing) is not upstream so this change should not
break audio on the n9/n950.

-- 
Péter

[toc] | [prev] | [next] | [standalone]

#1473890 — Re: [alsa-devel] [PATCH] ASoC: tlv320dac33: Remove deprecated create_singlethread_workqueue

Hello, Peter.

On Wed, Aug 31, 2016 at 10:10:47PM +0300, Peter Ujfalusi wrote:
> > What kind of time frame are we talking about?  If it really needs high
> > priority, the right thing to do would be using a WQ_HIGHPRI workqueue.
> 
> In order to be tune the performance and power saving during audio playback
> lower is better, but consistency matters more to be able have stable system.
> I have some latency compensation in the code so it could tolerate some drift,
> but big spikes can cause the codec to go underflow and we can not recover from
> that w/o hard reset of the codec.

Gees, that's a brutal failure mode.

> I do believe that Linux got much better over the years since I wrote the dac33
> driver, so I'm fine with the move to system_wq. The most problematic mode (I
> think it was MODE7LP or smthing) is not upstream so this change should not
> break audio on the n9/n950.

Thanks for the explanation!

-- 
tejun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web