Thread (10 messages) 10 messages, 2 authors, 2021-06-17

Re: [PATCH v3 1/2] mm: compaction: support triggering of proactive compaction by user

From: Vlastimil Babka <hidden>
Date: 2021-06-17 14:37:29
Also in: linux-doc, linux-fsdevel, lkml

On 6/17/21 9:30 AM, Charan Teja Kalla wrote:
Thanks Vlastimil for your inputs!!

On 6/16/2021 5:29 PM, Vlastimil Babka wrote:
quoted
quoted
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>
---
changes in V2:
You forgot to also summarize the changes. Please do in next version.
I think we can get rid off 'proactive_defer' thread variable with the
timeout approach you suggested. But it is still requires to have one
additional variable 'proactive_compact_trigger', which main purpose is
to decide if the kcompactd wakeup is for proactive compaction or not.
Please see below code:
   if (wait_event_freezable_timeout() && !proactive_compact_trigger) {
	// do the non-proactive work
	continue
   }
   // do the proactive work
     .................

Thus I feel that on writing new proactiveness, it is required to do
wakeup_kcomppactd() + set a flag that this wakeup is for proactive work.

Am I failed to get your point here?
The check whether to do non-proactive work is already guarded by
kcompactd_work_requested(), which looks at pgdat->kcompactd_max_order and this
is set by wakeup_kcompactd().

So with a plain wakeup where we don't set pgdat->kcompactd_max_order will make
it consider proactive work instead and we don't need another trigger variable
AFAICS.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help