A request to understand the design decisions why tasklets were changed to workqueues eg. hci_rx_task() to hci_rx_work()

A request to understand the design decisions why tasklets were changed to workqueues eg. hci_rx_task() to hci_rx_work()

[Dean Jenkins]

Hi,

I am interested to the understand the design decisions for changing
from tasklets to workqueues.

Was there a fundamental flaw that necessitated the change ?

I am asking because I am getting a Bluetooth "scheduling while atomic"
failure on an ARM based 2.6.34 kernel (with some 2.6.37 Bluez
backports). Changing to workqueues would avoid this issue as a
workqueue use process context that can sleep.

Thanks for any info on the design decisions.

Regards,
Dean

Re: A request to understand the design decisions why tasklets were changed to workqueues eg. hci_rx_task() to hci_rx_work()

[Mat Martineau]

Dean -

On Tue, 17 Apr 2012, Dean Jenkins wrote:

> Hi,
>
> I am interested to the understand the design decisions for changing
> from tasklets to workqueues.
>
> Was there a fundamental flaw that necessitated the change ?
>
> I am asking because I am getting a Bluetooth "scheduling while atomic"
> failure on an ARM based 2.6.34 kernel (with some 2.6.37 Bluez
> backports). Changing to workqueues would avoid this issue as a
> workqueue use process context that can sleep.
>
> Thanks for any info on the design decisions.

Take a look at http://article.gmane.org/gmane.linux.bluez.kernel/19535 
and the thread it is part of.  The main motivation was to eliminate 
bugs and complexity arising from a mix of tasklet-context and 
process-context code.  Locking and concurrency problems have become 
trickier with the introduction of the management interface, L2CAP 
ERTM, and AMP.

There were big changes to the workqueue internals in 2.6.36, I don't 
know if that will cause major issues when backporting current code to 
2.6.34.

--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum