hi all,
My question is regarding the correct use of workqueues. I have a
driver which queues a work item in the interrupt handler. The bottom
half function ( the workitem -function ) does have proper locking (
mutex ) in place for atomicity.
With this setup, since the interrupts are enabled, it's possible to
have a scenario where, when one workitem is being executed, another
can be queued up, which results in the workitems being executed in
parallel, however since there is a mutex, one thread will sleep.
is this particular scenario considered bad or discouraged ?
Thank you,
-Roshan
On Tue, Feb 10, 2015 at 1:50 AM, Roshan A [off-list ref] wrote:
hi all,
My question is regarding the correct use of workqueues. I have a
driver which queues a work item in the interrupt handler. The bottom
half function ( the workitem -function ) does have proper locking (
mutex ) in place for atomicity.
With this setup, since the interrupts are enabled, it's possible to
have a scenario where, when one workitem is being executed, another
can be queued up, which results in the workitems being executed in
parallel, however since there is a mutex, one thread will sleep.
You gain when most work items execute without contention. So perhaps
you can redesign that your work handlers would execute most of the
time without needing to lock.
Perhaps you can send data to handler func exclusively from top-half.
If you've anything global to maintain see if you can minimize the
contention code.
is this particular scenario considered bad or discouraged ?
Thank you,
-Roshan
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Feb 10, 2015, at 12:50 AM, Roshan A [off-list ref] wrote:
hi all,
My question is regarding the correct use of workqueues. I have a
driver which queues a work item in the interrupt handler. The bottom
half function ( the workitem -function ) does have proper locking (
mutex ) in place for atomicity.
Post the code snippet and why are you using
Mutex? If you want to synchronize between
Interrupt handler and workqueue then you should
use spinlocks.
With this setup, since the interrupts are enabled, it's possible to
have a scenario where, when one workitem is being executed, another
can be queued up, which results in the workitems being executed in
parallel, however since there is a mutex, one thread will sleep.
And precisely the reason not to use mutex locks.
is this particular scenario considered bad or discouraged ?
On Tue, Feb 10, 2015 at 9:24 AM, Anish Kumar
[off-list ref] wrote:
quoted
On Feb 10, 2015, at 12:50 AM, Roshan A [off-list ref] wrote:
hi all,
My question is regarding the correct use of workqueues. I have a
driver which queues a work item in the interrupt handler. The bottom
half function ( the workitem -function ) does have proper locking (
mutex ) in place for atomicity.
Post the code snippet and why are you using
Mutex? If you want to synchronize between
Interrupt handler and workqueue then you should
use spinlocks.
To clarify : the critical section is in the workitem-function. There
is no sharing between the interrupt handler and the bottom half.
quoted
With this setup, since the interrupts are enabled, it's possible to
have a scenario where, when one workitem is being executed, another
can be queued up, which results in the workitems being executed in
parallel, however since there is a mutex, one thread will sleep.
And precisely the reason not to use mutex locks.
quoted
is this particular scenario considered bad or discouraged ?
Hello Roshan,
On Tue, Feb 10, 2015 at 2:20 PM, Roshan A [off-list ref] wrote:
hi all,
My question is regarding the correct use of workqueues. I have a
driver which queues a work item in the interrupt handler. The bottom
half function ( the workitem -function ) does have proper locking (
mutex ) in place for atomicity.
With this setup, since the interrupts are enabled, it's possible to
have a scenario where, when one workitem is being executed, another
can be queued up, which results in the workitems being executed in
parallel, however since there is a mutex, one thread will sleep.
is this particular scenario considered bad or discouraged ?
Thanks Arun for the link. This clears up things for me.
On Wed, Feb 11, 2015 at 3:28 AM, Arun KS [off-list ref] wrote:
Hello Roshan,
On Tue, Feb 10, 2015 at 2:20 PM, Roshan A [off-list ref] wrote:
quoted
hi all,
My question is regarding the correct use of workqueues. I have a
driver which queues a work item in the interrupt handler. The bottom
half function ( the workitem -function ) does have proper locking (
mutex ) in place for atomicity.
With this setup, since the interrupts are enabled, it's possible to
have a scenario where, when one workitem is being executed, another
can be queued up, which results in the workitems being executed in
parallel, however since there is a mutex, one thread will sleep.
is this particular scenario considered bad or discouraged ?