Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[2\.6\.36\-rc3\]\s+Workqueues\,\s+XFS\,\s+dependencies\s+and\s+deadlocks\s*$/: 18 ]

Total 18 documents matching your query.

1. [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 Sep 2010 17:29:54 +1000
Hi Tejun, I've got a few concerns about workqueue consolidation it has gone into 2.6.36-rc and the way XFS has been using workqueues for concurrency and deadlock avoidance in IO completion. To give y
/archives/xfs/2010-09/msg00083.html (14,043 bytes)

2. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Tue, 07 Sep 2010 11:04:59 +0200
Hello, This is puzzling. Queueing order shouldn't have changed. Maybe I screwed up queueing order handling of delayed works. Which workqueue is this? Or better, can you give me a small test case whic
/archives/xfs/2010-09/msg00084.html (12,334 bytes)

3. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 Sep 2010 20:01:08 +1000
The three workqueues are initialised in fs/xfs/linux-2.6/xfs_buf.c::xfs_buf_init(). They do not use delayed works, the requeuing of interest here occurs in .../xfs_aops.c::xfs_end_io via .../xfs_aops
/archives/xfs/2010-09/msg00085.html (15,240 bytes)

4. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Tue, 07 Sep 2010 12:35:46 +0200
Hello, Oh, I was talking about cwq->delayed_works which is a mechanism which is used to enforce max_active among other things. I see. Heh, sorry about that. I'm writing it now. The plan is to audit a
/archives/xfs/2010-09/msg00086.html (12,938 bytes)

5. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Tue, 07 Sep 2010 14:26:54 +0200
Ooh, almost forgot. There was nr_active underflow bug in workqueue code which could lead to malfunctioning max_active regulation and problems during queue freezing, so you could be hitting that too.
/archives/xfs/2010-09/msg00088.html (10,040 bytes)

6. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 Sep 2010 22:48:50 +1000
Ok. Do you have an advance draft of the docco I can read? Almost. What happens is that there is a queue of data IO completions on q0, say w1...wN where wX is in the middle of the queue. wX requires l
/archives/xfs/2010-09/msg00089.html (15,528 bytes)

7. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 Sep 2010 23:02:43 +1000
I'm currently running with the WQ_HIGHPRI flag. I only change one thing at a time so I can tell what caused the change in behaviour... Well, most of the time the system is 100% unresponsive when the
/archives/xfs/2010-09/msg00090.html (10,719 bytes)

8. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Tue, 07 Sep 2010 17:39:48 +0200
Hello, Including half-finished one at the end of this mail. I see. The use case itself shouldn't be problematic at all for cmwq (sans bugs of course). In the other reply, you said "the system is 100%
/archives/xfs/2010-09/msg00092.html (23,815 bytes)

9. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 8 Sep 2010 17:34:28 +1000
Actually, it is. You don't need to burn CPU to livelock, you just need a loop in the state machine that cannot be broken by internal or external events to be considered livelocked. However, this is n
/archives/xfs/2010-09/msg00102.html (15,718 bytes)

10. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 08 Sep 2010 10:20:27 +0200
Hello, Yeah, but for the system to be completely unresponsive even to sysrq, the system needs to be live/dead locked in a pretty specific way. Cool, but please keep in mind that the nr_active underfl
/archives/xfs/2010-09/msg00104.html (13,058 bytes)

11. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 8 Sep 2010 18:22:49 +1000
Ok, it looks as if the WQ_HIGHPRI is all that was required to avoid the log IO completion starvation livelocks. I haven't yet pulled the tree below, but I've now created about a billion inodes withou
/archives/xfs/2010-09/msg00105.html (12,007 bytes)

12. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 8 Sep 2010 18:28:19 +1000
Ok, so the normal case is that they will all be processed local to the CPU they were queued on, like the old workqueue code? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
/archives/xfs/2010-09/msg00106.html (11,284 bytes)

13. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 08 Sep 2010 10:46:13 +0200
Hello, Bound workqueues always process works locally. Please consider the following scenario. w0, w1, w2 are queued to q0 on the same CPU. w0 burns CPU for 5ms then sleeps for 10ms then burns CPU for
/archives/xfs/2010-09/msg00107.html (11,746 bytes)

14. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 08 Sep 2010 10:51:28 +0200
Hello, Great, BTW, I have several questions regarding wq usage in xfs. * Do you think @max_active > 1 could be useful for xfs? If most works queued on the wq are gonna contend for the same (blocking)
/archives/xfs/2010-09/msg00108.html (12,391 bytes)

15. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 8 Sep 2010 20:05:03 +1000
It may indeed help, but I can't really say much more than that right now. I need a deeper understanding of the impact of increasing max_active (I have a basic understanding now) before I could say fo
/archives/xfs/2010-09/msg00110.html (14,545 bytes)

16. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 8 Sep 2010 20:12:22 +1000
Ok, so in this case if this was on CPU 1, I'd see kworker[1:0], kworker[1:1] and kworker[1:2] threads all accumulate CPU time? I'm just trying to relate your example it to behaviour I've seen to chec
/archives/xfs/2010-09/msg00111.html (12,386 bytes)

17. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 08 Sep 2010 12:28:40 +0200
Hello, Yes, you're right. If all three works just burn CPU cycles for 5ms then you'll only see one kworker w/ 15ms of accumulated CPU time. Thanks. -- tejun
/archives/xfs/2010-09/msg00112.html (10,871 bytes)

18. Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks (score: 1)
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 08 Sep 2010 16:10:55 +0200
Hello, Sure, things should be fine as they currently stand. No need to hurry anything. I see. I'll soon send out a patch to convert xfs to use alloc_workqueue() instead and will drop singlethread res
/archives/xfs/2010-09/msg00115.html (13,165 bytes)


This search system is powered by Namazu