Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1283416
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue |
| Date | 2015-12-03 23:10 +0100 |
| Message-ID | <qBKeC-2ve-13@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <qBDGa-6Nq-17@gated-at.bofh.it> <qBHJL-QO-1@gated-at.bofh.it> <qBIZb-1y2-5@gated-at.bofh.it> <qBJ8T-1Cs-61@gated-at.bofh.it> <qBJiz-1Vy-33@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hello, Peter. On Thu, Dec 03, 2015 at 10:09:11PM +0100, Peter Zijlstra wrote: > On Thu, Dec 03, 2015 at 03:56:32PM -0500, Tejun Heo wrote: > > So, if I'm not mistaken, those are all marking tasks which can be > > depended upon during memory reclaim and we do want to catch them all. > > Up to a point yes, these are things that want to be reliable during > reclaim, but lacking memory reserves and usage bounds (which we > discussed last at lsf/mm) these are just wanna-be. Hmmm... even if buggy in that they can't guarantee forward-progress even with access to the emergency pool, I think it makes sense to warn them about creating an extra dependency which doesn't have access to the emergency pool. > > PF_MEMALLOC shouldn't depend on something which require memory to be > > reclaimed to guarantee forward progress. > > PF_MEMALLOC basically avoids reclaim for any memory allocation while its > set. So, the assumption is that they're already on the reclaim path and thus shouldn't recurse into it again. > The thing is, even if your workqueue has WQ_MEM_RECLAIM set, it will not > hit the mayday button until you're completely full flat out of memory. It's more trigger-happy than that. It's timer based. If new worker can't be created for a certain amount of time for whatever reason, it'll summon the rescuer. > At which point you're probably boned anyway, because, as per the above, > all that code assumes there's _some_ memory to be had. Not really. PF_MEMALLOC tasks have access to the emergency pool, creating new workers doesn't, so this really is creating a dependency which is qualitatively different. > One solution is to always fail maybe_create_worker() when PF_MEMALLOC is > set, thus always hitting the mayday button. I'm not following. When PF_MEMALLOC is set where? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Tejun Heo <tj@kernel.org> - 2015-12-03 01:30 +0100
[PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 01:30 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 15:50 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-03 19:00 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 20:50 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Ulrich Obergfell <uobergfe@redhat.com> - 2015-12-03 21:20 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 22:00 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Ingo Molnar <mingo@kernel.org> - 2015-12-04 09:10 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-04 18:00 +0100
Re: [PATCH 2/2] workqueue: implement lockup detector Ulrich Obergfell <uobergfe@redhat.com> - 2015-12-04 14:30 +0100
[PATCH v2 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-07 20:10 +0100
Re: [PATCH v2 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-07 22:40 +0100
Re: [PATCH v2 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-08 17:10 +0100
Re: [PATCH v2 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-08 17:40 +0100
Re: [PATCH v2 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-07 22:40 +0100
Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Peter Zijlstra <peterz@infradead.org> - 2015-12-03 10:40 +0100
Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Peter Zijlstra <peterz@infradead.org> - 2015-12-03 11:10 +0100
Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Tejun Heo <tj@kernel.org> - 2015-12-03 15:50 +0100
Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Tejun Heo <tj@kernel.org> - 2015-12-03 16:10 +0100
[PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-03 20:30 +0100
Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Peter Zijlstra <peterz@infradead.org> - 2015-12-03 21:50 +0100
Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-03 22:00 +0100
Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Peter Zijlstra <peterz@infradead.org> - 2015-12-03 22:10 +0100
Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-03 23:10 +0100
Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Peter Zijlstra <peterz@infradead.org> - 2015-12-04 14:00 +0100
Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-07 17:00 +0100
Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Peter Zijlstra <peterz@infradead.org> - 2015-12-03 16:10 +0100
csiph-web