Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1410622 > unrolled thread

[PATCH] mm/swap: lru drain on memory reclaim workqueue

Started byKeith Busch <keith.busch@intel.com>
First post2016-05-31 23:00 +0200
Last post2016-05-31 23:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [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

#1410622 — [PATCH] mm/swap: lru drain on memory reclaim workqueue

FromKeith Busch <keith.busch@intel.com>
Date2016-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]


#1410624

FromTejun Heo <tj@kernel.org>
Date2016-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]


#1410630

FromKeith Busch <keith.busch@intel.com>
Date2016-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