Re: [PATCH] mm/ksm: introduce ksm_enabled for each process

On Thu 19-05-22 06:23:30, CGEL wrote:

On Wed, May 18, 2022 at 02:12:26PM +0200, Michal Hocko wrote:

quoted

On Wed 18-05-22 02:47:06, CGEL wrote:

quoted

On Tue, May 17, 2022 at 04:04:38PM +0200, Michal Hocko wrote:

quoted

[CCing Hugh and linux-api]

On Tue 17-05-22 09:27:01, cgel.zte@gmail.com wrote:

quoted

From: xu xin <redacted>

For now, if we want to use KSM to merge pages of some apps, we have to
explicitly call madvise() in application code, which means installed
apps on OS needs to be uninstall and source code needs to be modified.
It is very inconvenient because sometimes users or app developers are not
willing to modify their app source codes for any reasons.

Hello, Michal.

quoted

Would it help to allow external control by process_madvise?

Maybe, but it will be much more complicated to achieve this by
process_madvise(). process_madvise works on a serires of VMAs in
essential, So all the eligible VMAs have to be traversed. The problem
about this has been discussed in [1],[2].
[1]https://lore.kernel.org/lkml/1835064.A2aMcgg3dW@natalenko.name/ (local)
[2]https://lore.kernel.org/lkml/20220513133210.9dd0a4216bd8baaa1047562c@linux-foundation.org/ (local)

I can see that this is not a trivial interface to use but I do not
think this would be too hard to be usable. There is certainly some
coordination required between the external and the target tasks. But
that is to be expected IMHO. You do not really want to configure merging
without actually understanding what the application does and whether
that is really OK. Right?

Besides that, as far as I remember, the process_madvise interface
doesn't really require exact vmas to be provided and a single range can
span multiple VMAs.

Yes, but all the eligible VMAs still have to be traversed after all. It may
induce more latency than needed because the target task has to be
stopped to avoid races.

Does it really? I mean, you are right that some sort of synchronization
(e.g. freezing) is required to prevent from address space modifications.
My question is whether this is really required for something that is
mostly an optimization. Missing some VMAs or failing because of racing
modifications is should be toleratable. Or am I wrong on that?
 

quoted

quoted

quoted

quoted

So to use KSM more flexibly, we provide a new proc file "ksm_enabled" under
/proc/<pid>/. We can pass parameter into this file with one of three values
as follows:

	always:
		force all anonymous and eligible VMAs of this process to be
		scanned by ksmd.
	madvise:
		the default state, unless user code call madvise, ksmd
		doesn't scan this process.
	never:
		this process will never be scanned by ksmd and no merged
		pages occurred in this process.

With this patch, we can control KSM with ``/proc/<pid>/ksm_enabled``
based on every process. KSM for each process can be entirely disabled
(mostly for debugging purposes) or only enabled inside MADV_MERGEABLE
regions (to avoid the risk of consuming more cpu resources to scan for
ksmd) or enabled entirely for a process.

I am not really familiar with KSM much but I am wondering whether the
proc based interface is really the best fit. We have a very similar
concern with THP where processes would like to override the global setup
and that has been done with prctl interface. Is there any reason why
this should be any different?

At least for now, I can't find a simpler implementation than proc file,
unless we add a new syscall used for changing another process mm's flag
in user space.

What is the problem with the prctl extension?

What's the meaning of the prctl extension?

Add a new prctl "command"

I don't quite get your point. Can prctl control external process?

Not directly but the properties set by prctl are usually inherited so it
is trivial to create a spawn process to set up the property and exec
into the target application. The target application is not really aware
it has been executed like that so it doesn't really need any
modifications.

But please note that I am not really suggesting to go with prctl. I am
just saying it is a better interface than proc one. I am still not
convinced this really required and I would prefer process_madvise more.
 

quoted

quoted

Speaking to THP, the interactive UI of KSM is relatively simpler because
KSM dosen't have global knob like THP. OTOH, THP trades space for time
(consume memory) while KSM trades time for space (save memory), so THP
tends to be enabled system wide while KSM not.

quoted

Another question I have is about the interaction of the per-process
tunable with any explicit madvise calls. AFAICS you have made this knob
per mm but the actual implementation currently relies on the per-vma
flags. That means that one can explicitly disallow merging by madvise
for a range. Is it wise to override that by a per-process knob? I mean
there might be a very good reason why a particular memory ranges should
never be merged but a per-process knob could easily ignore that hint
from the application. Or am I just confuse?

For now, there is no any hints for letting KSM never merge some memory
ranges.

I am not sure I understand. Could you be more specific?

Not like THP, KSM doesn't have anything like VM_NOHUGEPAGE, so apps
cann't explicitly disallow merging by madvise. If it is really necessary for
a particular meory ranges of a process to be never merged, we have to submit
one more patch to achieve that.

What about MADV_UNMERGEABLE?
-- 
Michal Hocko
SUSE Labs