linux-kernel - Re: [PATCH 2/3] mm/ksm: Support prctl controlling KSM with pid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240903041314.1775342-1-xu.xin16@zte.com.cn>
Date: Tue,  3 Sep 2024 04:13:14 +0000
From: xu xin <xu.xin.sc@...il.com>
To: david@...hat.com
Cc: linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	shr@...kernel.io,
	hughd@...gle.com
Subject: Re: [PATCH 2/3] mm/ksm: Support prctl controlling KSM with pid

Thanks for your reply.

Selection of interface
======================

At this point, I have been thinking for a long time, and in order to achieve
the control of the KSM scanning of an already running process, the current
prctl PR_SET_MEMORY_MERGE is the most suitable interface. On the one hand,
it is compatible with the existing KSM PRCTL interface, making it easier
for users to get used to and adapt to it; On the other hand, it adds prctl
control over processes that have already been started through PID. Lastly,
I referred to the PR_SCHED_CORE option of prctl, which also uses arg3 to
perform operations on tasks pointed to by specific PID.

Anyway, the current way may not necessarily violates "prctl() manipulates
various aspects of the behavior of the calling thread or process." ,
becasue we can consider controlling KSM scanning of pid as a behavior of
the calling thread.

By the way, I explain some more about why we want to manipulates KSM
behavior of an already running process.

Purpose (or usecase):
=====================

In the field of embedded Linux for cost considerations, resources including
cpu and memory, are often not very sufficient, so the global deployment of
KSM can be a mitigation strategy, which is feasible for closed system
(scenarios without Internet connection). However, KSM has a side effect of
increasing write time replication latency, which is somewhat unacceptable
for latency sensitive applications. Therefore, it can be combined with the
QoS of the business tasks to dynamically close some part of those already
started processes in real time if the QoS degrade. Although it is also
beneficial for server/cloud OS, the requirement of embedded system is more
urgent and strong compared to cloud or server operating systems with
sufficient memory.