Re: [PATCH V2] mm: compaction: support triggering of proactive compaction by user

Started by Vlastimil Babka on May 28, 2021 · 2 messages from 2 authors · Last reply May 28, 2021

open the first message on its own page

Message details and related content
+CC linux-api

On 5/18/21 3:37 PM, Charan Teja Reddy wrote:
The proactive compaction[1] gets triggered for every 500msec and run
compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9)
pages based on the value set to sysctl.compaction_proactiveness.
Triggering the compaction for every 500msec in search of
COMPACTION_HPAGE_ORDER pages is not needed for all applications,
especially on the embedded system usecases which may have few MB's of
RAM. Enabling the proactive compaction in its state will endup in
running almost always on such systems.

Other side, proactive compaction can still be very much useful for
getting a set of higher order pages in some controllable
manner(controlled by using the sysctl.compaction_proactiveness). Thus on
systems where enabling the proactive compaction always may proove not
required, can trigger the same from user space on write to its sysctl
interface. As an example, say app launcher decide to launch the memory
heavy application which can be launched fast if it gets more higher
order pages thus launcher can prepare the system in advance by
triggering the proactive compaction from userspace.

This triggering of proactive compaction is done on a write to
sysctl.compaction_proactiveness by user.

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=facdaa917c4d5a376d09d25865f5a863f906234a

Signed-off-by: Charan Teja Reddy <redacted>
Cancelling all current sleeps immediately when the controlling variable changes
doesn't sound wrong to me.
A question below:
quoted hunk
---
changes in V2: 
    - remove /proc interface trigger for proactive compaction
    - Intention is same that add a way to trigger proactive compaction by user.

changes in V1:
    -  https://lore.kernel.org/lkml/1619098678-8501-1-git-send-email-charante@codeaurora.org/

 include/linux/compaction.h |  2 ++
 include/linux/mmzone.h     |  1 +
 kernel/sysctl.c            |  2 +-
 mm/compaction.c            | 35 ++++++++++++++++++++++++++++++++---
 4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 4221888..04d5d9f 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -84,6 +84,8 @@ static inline unsigned long compact_gap(unsigned int order)
 extern unsigned int sysctl_compaction_proactiveness;
 extern int sysctl_compaction_handler(struct ctl_table *table, int write,
 			void *buffer, size_t *length, loff_t *ppos);
+extern int compaction_proactiveness_sysctl_handler(struct ctl_table *table,
+		int write, void *buffer, size_t *length, loff_t *ppos);
 extern int sysctl_extfrag_threshold;
 extern int sysctl_compact_unevictable_allowed;
 
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0d53eba..9455809 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -815,6 +815,7 @@ typedef struct pglist_data {
 	enum zone_type kcompactd_highest_zoneidx;
 	wait_queue_head_t kcompactd_wait;
 	struct task_struct *kcompactd;
+	bool proactive_compact_trigger;
 #endif
 	/*
 	 * This is a per-node reserve of pages that are not available
diff --git a/kernel/sysctl.c b/kernel/sysctl.c

73 more quoted lines

I don't understand this part. If we kick kcompactd from the sysctl handler
because we are changing proactiveness, shouldn't we also discard any accumulated
defer score?
quoted hunk
 			}
 			prev_score = fragmentation_score_node(pgdat);
 			proactive_compact_node(pgdat);
@@ -2931,6 +2957,9 @@ static int kcompactd(void *p)
 			proactive_defer = score < prev_score ?
 					0 : 1 << COMPACT_MAX_DEFER_SHIFT;
 		}
+loop:
+		if (pgdat->proactive_compact_trigger)
+			pgdat->proactive_compact_trigger = false;
 	}
 
 	return 0;
Message details and related content
Thanks Vlastimil for your inputs!!

On 5/28/2021 8:49 PM, Vlastimil Babka wrote:
On 5/18/21 3:37 PM, Charan Teja Reddy wrote:
quoted
The proactive compaction[1] gets triggered for every 500msec and run
compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9)
pages based on the value set to sysctl.compaction_proactiveness.
Triggering the compaction for every 500msec in search of
COMPACTION_HPAGE_ORDER pages is not needed for all applications,
especially on the embedded system usecases which may have few MB's of
RAM. Enabling the proactive compaction in its state will endup in
running almost always on such systems.
This triggering of proactive compaction is done on a write to
sysctl.compaction_proactiveness by user.

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=facdaa917c4d5a376d09d25865f5a863f906234a

Signed-off-by: Charan Teja Reddy <redacted>
Cancelling all current sleeps immediately when the controlling variable changes
doesn't sound wrong to me.
Agree that cancelling sleeps is not wrong here.
A question below:
quoted
---
changes in V2: 
    - remove /proc interface trigger for proactive compaction
    - Intention is same that add a way to trigger proactive compaction by user.
 			if (proactive_defer) {
 				proactive_defer--;
-				continue;
+				goto loop;
I don't understand this part. If we kick kcompactd from the sysctl handler
because we are changing proactiveness, shouldn't we also discard any accumulated
defer score?
Yes, we should be discarding the accumulated defer score when user
changing the proactiveness, even when writing higher proactiveness value
than for which it was deferred. Will raise V3 for this.
--Charan
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Projec t
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help