aboutsummaryrefslogtreecommitdiff
path: root/fs/jbd2/commit.c
diff options
context:
space:
mode:
authorFrederic Weisbecker <[email protected]>2014-05-23 18:10:21 +0200
committerFrederic Weisbecker <[email protected]>2014-06-16 16:26:53 +0200
commitb93e0b8fa819c3d5641794ed9a07e643416aa0fd (patch)
tree7f69d9083da0b366482eed6d94ce8123762c4994 /fs/jbd2/commit.c
parent7171511eaec5bf23fb06078f59784a3a0626b38f (diff)
irq_work: Split raised and lazy lists
An irq work can be handled from two places: from the tick if the work carries the "lazy" flag and the tick is periodic, or from a self IPI. We merge all these works in a single list and we use some per cpu latch to avoid raising a self-IPI when one is already pending. Now we could do away with this ugly latch if only the list was only made of non-lazy works. Just enqueueing a work on the empty list would be enough to know if we need to raise an IPI or not. Also we are going to implement remote irq work queuing. Then the per CPU latch will need to become atomic in the global scope. That's too bad because, here as well, just enqueueing a work on an empty list of non-lazy works would be enough to know if we need to raise an IPI or not. So lets take a way out of this: split the works in two distinct lists, one for the works that can be handled by the next tick and another one for those handled by the IPI. Just checking if the latter is empty when we queue a new work is enough to know if we need to raise an IPI. Suggested-by: Peter Zijlstra <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Viresh Kumar <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]>
Diffstat (limited to 'fs/jbd2/commit.c')
0 files changed, 0 insertions, 0 deletions