2012-04-17 11:28:15

by Dean Jenkins

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

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

2012-04-17 15:09:13

by Mat Martineau

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

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