From: Tejun Heo <tj@kernel.org> To: Dave Chinner <david@fromorbit.com> 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 10:18:36 -0400 [thread overview] Message-ID: <20140625141836.GC26883@htj.dyndns.org> (raw) In-Reply-To: <20140625055641.GL9508@dastard> Hello, Dave. On Wed, Jun 25, 2014 at 03:56:41PM +1000, Dave Chinner wrote: > 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. >From Documentation/workqueue.txt WQ_MEM_RECLAIM All wq which might be used in the memory reclaim paths _MUST_ have this flag set. The wq is guaranteed to have at least one execution context regardless of memory pressure. So, all that's guaranteed is that the workqueue has at least one worker executing its work items. If that one worker is serving a work item which can't make forward progress, the workqueue is not guaranteed to make forward progress. > 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.... I'd love to provide that but guaranteeing that at least one work is always being executed requires unlimited task allocation (the ones which get blocked gotta store their context somewhere). > > 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? Documentation/workqueue.txt should be it but maybe we should be more explicit. The behavior is maintaining what the pre-concurrency-management workqueue provided with static per-workqueue workers. Each workqueue reserved its workers (either one per cpu or one globally) and it only supported single level of concurrency on each CPU. WQ_MEM_RECLAIM is providing equivalent amount of forward progress guarantee and all the existing users shouldn't have issues on this front. If we have grown incorrect usages from then on, we need to fix them. Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org> To: Dave Chinner <david@fromorbit.com> 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 10:18:36 -0400 [thread overview] Message-ID: <20140625141836.GC26883@htj.dyndns.org> (raw) In-Reply-To: <20140625055641.GL9508@dastard> Hello, Dave. On Wed, Jun 25, 2014 at 03:56:41PM +1000, Dave Chinner wrote: > 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. >From Documentation/workqueue.txt WQ_MEM_RECLAIM All wq which might be used in the memory reclaim paths _MUST_ have this flag set. The wq is guaranteed to have at least one execution context regardless of memory pressure. So, all that's guaranteed is that the workqueue has at least one worker executing its work items. If that one worker is serving a work item which can't make forward progress, the workqueue is not guaranteed to make forward progress. > 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.... I'd love to provide that but guaranteeing that at least one work is always being executed requires unlimited task allocation (the ones which get blocked gotta store their context somewhere). > > 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? Documentation/workqueue.txt should be it but maybe we should be more explicit. The behavior is maintaining what the pre-concurrency-management workqueue provided with static per-workqueue workers. Each workqueue reserved its workers (either one per cpu or one globally) and it only supported single level of concurrency on each CPU. WQ_MEM_RECLAIM is providing equivalent amount of forward progress guarantee and all the existing users shouldn't have issues on this front. If we have grown incorrect usages from then on, we need to fix them. Thanks. -- tejun _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-25 14:18 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 2014-06-25 5:56 ` Dave Chinner 2014-06-25 14:18 ` Tejun Heo [this message] 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=20140625141836.GC26883@htj.dyndns.org \ --to=tj@kernel.org \ --cc=austin@peloton-tech.com \ --cc=david@fromorbit.com \ --cc=linux-kernel@vger.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.