On 7/30/21 4:46 PM, Charan Teja Kalla wrote:

Thanks Vlastimil!!

On 7/30/2021 7:36 PM, Vlastimil Babka wrote:

quoted

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.

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). So, 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>

Acked-by: Vlastimil Babka <redacted>

Thanks for the tag here.

Np.

quoted

quoted

@@ -2895,9 +2920,16 @@ static int kcompactd(void *p)
 	while (!kthread_should_stop()) {
 		unsigned long pflags;
 
+		/*
+		 * Avoid the unnecessary wakeup for proactive compaction
+		 * when it is disabled.
+		 */
+		if (!sysctl_compaction_proactiveness)
+			timeout = MAX_SCHEDULE_TIMEOUT;

Does this part actually logically belong more to your previous patch that
optimized the deferred timeouts?

IMO, it won't fit there. Reason is that when user writes
sysctl_compaction_proactiveness = 0, it will goes to sleep with
MAX_SCHEDULE_TIMEOUT. Say now user writes non-zero value to
sysctl_compaction_proactiveness then no condition is there to wake it up
for proactive compaction, means, it will still be in sleep with
MAX_SCHEDULE_TIMEOUT.

Good point!

Thus this logic is put in this patch, where, proactive compaction work
will be scheduled immediately on switch of proactiveness value from zero
to a non-zero.

Agreed. Thanks!

quoted