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
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
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
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
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.
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
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
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%
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
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
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
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
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
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)
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
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
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
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