Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1410622 > unrolled thread
| Started by | Keith Busch <keith.busch@intel.com> |
|---|---|
| First post | 2016-05-31 23:00 +0200 |
| Last post | 2016-05-31 23:10 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] mm/swap: lru drain on memory reclaim workqueue Keith Busch <keith.busch@intel.com> - 2016-05-31 23:00 +0200
Re: [PATCH] mm/swap: lru drain on memory reclaim workqueue Tejun Heo <tj@kernel.org> - 2016-05-31 23:10 +0200
Re: [PATCH] mm/swap: lru drain on memory reclaim workqueue Keith Busch <keith.busch@intel.com> - 2016-05-31 23:10 +0200
| From | Keith Busch <keith.busch@intel.com> |
|---|---|
| Date | 2016-05-31 23:00 +0200 |
| Subject | [PATCH] mm/swap: lru drain on memory reclaim workqueue |
| Message-ID | <rEYVA-7tn-13@gated-at.bofh.it> |
This creates a system memory reclaim work queue and has lru_add_drain_all
use this new work queue. This allows memory reclaim work that invalidates
block devices to flush all lru add caches without triggering the
check_flush_dependency warning.
Signed-off-by: Keith Busch <keith.busch@intel.com>
---
This is similar to proposal a few months ago:
https://patchwork.ozlabs.org/patch/574623/
The difference from this patch is this one uses a system workqueue so
others can use a memory reclaim workqueue without having to allocate
their own.
I didn't see any follow up on linux-mm on if lru_add_drain_per_cpu
should be using a WQ_MEM_RECLAIM set work queue, so sending a similar
patch since warnings are frequently being triggered.
include/linux/workqueue.h | 1 +
kernel/workqueue.c | 5 ++++-
mm/swap.c | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index ca73c50..8c79e82 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -357,6 +357,7 @@ extern struct workqueue_struct *system_unbound_wq;
extern struct workqueue_struct *system_freezable_wq;
extern struct workqueue_struct *system_power_efficient_wq;
extern struct workqueue_struct *system_freezable_power_efficient_wq;
+extern struct workqueue_struct *system_mem_wq;
extern struct workqueue_struct *
__alloc_workqueue_key(const char *fmt, unsigned int flags, int max_active,
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5f5068e..7e9050a 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -341,6 +341,8 @@ struct workqueue_struct *system_long_wq __read_mostly;
EXPORT_SYMBOL_GPL(system_long_wq);
struct workqueue_struct *system_unbound_wq __read_mostly;
EXPORT_SYMBOL_GPL(system_unbound_wq);
+struct workqueue_struct *system_mem_wq __read_mostly;
+EXPORT_SYMBOL(system_mem_wq);
struct workqueue_struct *system_freezable_wq __read_mostly;
EXPORT_SYMBOL_GPL(system_freezable_wq);
struct workqueue_struct *system_power_efficient_wq __read_mostly;
@@ -5574,6 +5576,7 @@ static int __init init_workqueues(void)
system_long_wq = alloc_workqueue("events_long", 0, 0);
system_unbound_wq = alloc_workqueue("events_unbound", WQ_UNBOUND,
WQ_UNBOUND_MAX_ACTIVE);
+ system_mem_wq = alloc_workqueue("events_mem_unbound", WQ_UNBOUND | WQ_MEM_RECLAIM, 0);
system_freezable_wq = alloc_workqueue("events_freezable",
WQ_FREEZABLE, 0);
system_power_efficient_wq = alloc_workqueue("events_power_efficient",
@@ -5582,7 +5585,7 @@ static int __init init_workqueues(void)
WQ_FREEZABLE | WQ_POWER_EFFICIENT,
0);
BUG_ON(!system_wq || !system_highpri_wq || !system_long_wq ||
- !system_unbound_wq || !system_freezable_wq ||
+ !system_mem_wq || !system_unbound_wq || !system_freezable_wq ||
!system_power_efficient_wq ||
!system_freezable_power_efficient_wq);
diff --git a/mm/swap.c b/mm/swap.c
index 03aacbc..ade23de 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -685,7 +685,7 @@ void lru_add_drain_all(void)
pagevec_count(&per_cpu(lru_deactivate_pvecs, cpu)) ||
need_activate_page_drain(cpu)) {
INIT_WORK(work, lru_add_drain_per_cpu);
- schedule_work_on(cpu, work);
+ queue_work_on(cpu, system_mem_wq, work);
cpumask_set_cpu(cpu, &has_work);
}
}
--
2.7.2
[toc] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2016-05-31 23:10 +0200 |
| Message-ID | <rEZ5f-7LR-5@gated-at.bofh.it> |
| In reply to | #1410622 |
On Tue, May 31, 2016 at 02:50:15PM -0600, Keith Busch wrote:
> + system_mem_wq = alloc_workqueue("events_mem_unbound", WQ_UNBOUND | WQ_MEM_RECLAIM,
So, WQ_MEM_RECLAIM on a shared workqueue doesn't make much sense.
That flag guarantees single concurrency level to the workqueue. How
would multiple users of a shared workqueue coordinate around that?
What prevents one events_mem_unbound user from depending on, say,
draining lru? If lru draining requires a rescuer to guarantee forward
progress under memory pressure, that rescuer worker must be dedicated
for that purpose and can't be shared.
Thanks.
--
tejun
[toc] | [prev] | [next] | [standalone]
| From | Keith Busch <keith.busch@intel.com> |
|---|---|
| Date | 2016-05-31 23:10 +0200 |
| Message-ID | <rEZ5f-7LR-17@gated-at.bofh.it> |
| In reply to | #1410624 |
On Tue, May 31, 2016 at 05:01:16PM -0400, Tejun Heo wrote: > So, WQ_MEM_RECLAIM on a shared workqueue doesn't make much sense. > That flag guarantees single concurrency level to the workqueue. How > would multiple users of a shared workqueue coordinate around that? > What prevents one events_mem_unbound user from depending on, say, > draining lru? If lru draining requires a rescuer to guarantee forward > progress under memory pressure, that rescuer worker must be dedicated > for that purpose and can't be shared. Gotchya, that fixes my understanding on the rescuer thread operation. In this case, could we revive your previous proposal for consideration?
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web