From: Dave Chinner <david@fromorbit.com> To: Tejun Heo <tj@kernel.org> Cc: Austin Schuh <austin@peloton-tech.com>, xfs <xfs@oss.sgi.com>, linux-kernel@vger.kernel.org Subject: Re: On-stack work item completion race? (was Re: XFS crash?) Date: Wed, 25 Jun 2014 15:56:41 +1000 [thread overview] Message-ID: <20140625055641.GL9508@dastard> (raw) In-Reply-To: <20140624032521.GA12164@htj.dyndns.org> On Mon, Jun 23, 2014 at 11:25:21PM -0400, Tejun Heo wrote: > Hello, > > On Tue, Jun 24, 2014 at 01:02:40PM +1000, Dave Chinner wrote: > > As I understand it, what then happens is that the workqueue code > > grabs another kworker thread and runs the next work item in it's > > queue. IOWs, work items can block, but doing that does not prevent > > execution of other work items queued on other work queues or even on > > the same work queue. Tejun, did I get that correct? > > Yes, as long as the workqueue is under its @max_active limit and has > access to an existing kworker or can create a new one, it'll start > executing the next work item immediately; however, the guaranteed > level of concurrency is 1 even for WQ_RECLAIM workqueues. IOW, the > work items queued on a workqueue must be able to make forward progress > with single work item if the work items are being depended upon for > memory reclaim. Hmmm - that's different from my understanding of what the original behaviour WQ_MEM_RECLAIM gave us. i.e. that WQ_MEM_RECLAIM workqueues had a rescuer thread created to guarantee that the *workqueue* could make forward progress executing work in a reclaim context. The concept that the *work being executed* needs to guarantee forwards progress is something I've never heard stated before. That worries me a lot, especially with all the memory reclaim problems that have surfaced in the past couple of months.... > As long as a WQ_RECLAIM workqueue dosen't depend upon itself, > forward-progress is guaranteed. I can't find any documentation that actually defines what WQ_MEM_RECLAIM means, so I can't tell when or how this requirement came about. If it's true, then I suspect most of the WQ_MEM_RECLAIM workqueues in filesystems violate it. Can you point me at documentation/commits/code describing the constraints of WQ_MEM_RECLAIM and the reasons for it? Cheers, Dave. -- Dave Chinner david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: Tejun Heo <tj@kernel.org> Cc: linux-kernel@vger.kernel.org, Austin Schuh <austin@peloton-tech.com>, xfs <xfs@oss.sgi.com> Subject: Re: On-stack work item completion race? (was Re: XFS crash?) Date: Wed, 25 Jun 2014 15:56:41 +1000 [thread overview] Message-ID: <20140625055641.GL9508@dastard> (raw) In-Reply-To: <20140624032521.GA12164@htj.dyndns.org> On Mon, Jun 23, 2014 at 11:25:21PM -0400, Tejun Heo wrote: > Hello, > > On Tue, Jun 24, 2014 at 01:02:40PM +1000, Dave Chinner wrote: > > As I understand it, what then happens is that the workqueue code > > grabs another kworker thread and runs the next work item in it's > > queue. IOWs, work items can block, but doing that does not prevent > > execution of other work items queued on other work queues or even on > > the same work queue. Tejun, did I get that correct? > > Yes, as long as the workqueue is under its @max_active limit and has > access to an existing kworker or can create a new one, it'll start > executing the next work item immediately; however, the guaranteed > level of concurrency is 1 even for WQ_RECLAIM workqueues. IOW, the > work items queued on a workqueue must be able to make forward progress > with single work item if the work items are being depended upon for > memory reclaim. Hmmm - that's different from my understanding of what the original behaviour WQ_MEM_RECLAIM gave us. i.e. that WQ_MEM_RECLAIM workqueues had a rescuer thread created to guarantee that the *workqueue* could make forward progress executing work in a reclaim context. The concept that the *work being executed* needs to guarantee forwards progress is something I've never heard stated before. That worries me a lot, especially with all the memory reclaim problems that have surfaced in the past couple of months.... > As long as a WQ_RECLAIM workqueue dosen't depend upon itself, > forward-progress is guaranteed. I can't find any documentation that actually defines what WQ_MEM_RECLAIM means, so I can't tell when or how this requirement came about. If it's true, then I suspect most of the WQ_MEM_RECLAIM workqueues in filesystems violate it. Can you point me at documentation/commits/code describing the constraints of WQ_MEM_RECLAIM and the reasons for it? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-25 5:56 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-03-05 23:08 XFS crash? Austin Schuh 2014-03-05 23:35 ` Dave Chinner 2014-03-06 0:53 ` Austin Schuh 2014-05-13 1:29 ` Austin Schuh 2014-05-13 3:10 ` Austin Schuh 2014-05-13 3:33 ` Austin Schuh 2014-05-13 3:46 ` Dave Chinner 2014-05-13 4:03 ` Austin Schuh 2014-05-13 6:39 ` Dave Chinner 2014-05-13 7:02 ` Austin Schuh 2014-05-13 9:03 ` Dave Chinner 2014-05-13 17:11 ` Austin Schuh 2014-06-23 20:05 ` Austin Schuh 2014-06-24 3:02 ` On-stack work item completion race? (was Re: XFS crash?) Dave Chinner 2014-06-24 3:02 ` Dave Chinner 2014-06-24 3:25 ` Tejun Heo 2014-06-24 3:25 ` Tejun Heo 2014-06-25 3:05 ` Austin Schuh 2014-06-25 14:00 ` Tejun Heo 2014-06-25 14:00 ` Tejun Heo 2014-06-25 17:04 ` Austin Schuh 2014-06-25 17:04 ` Austin Schuh 2014-06-25 3:16 ` Austin Schuh 2014-06-25 3:16 ` Austin Schuh 2014-06-25 5:56 ` Dave Chinner [this message] 2014-06-25 5:56 ` Dave Chinner 2014-06-25 14:18 ` Tejun Heo 2014-06-25 14:18 ` Tejun Heo 2014-06-25 22:08 ` Dave Chinner 2014-06-25 22:08 ` Dave Chinner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140625055641.GL9508@dastard \ --to=david@fromorbit.com \ --cc=austin@peloton-tech.com \ --cc=linux-kernel@vger.kernel.org \ --cc=tj@kernel.org \ --cc=xfs@oss.sgi.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.