linux-kernel - Re: [PATCH 0/3] mm/ksm: Support 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-prev] [day] [month] [year] [list]

Message-Id: <20240907022309.1931368-1-xu.xin16@zte.com.cn>
Date: Sat,  7 Sep 2024 02:23:09 +0000
From: xu xin <xu.xin.sc@...il.com>
To: shr@...kernel.io
Cc: akpm@...ux-foundation.org,
	david@...hat.com,
	hughd@...gle.com,
	linux-kernel@...r.kernel.org,
	xu.xin.sc@...il.com,
	xu.xin16@....com.cn
Subject: Re: [PATCH 0/3] mm/ksm: Support controlling KSM with PID

> xu xin <xu.xin.sc@...il.com> writes:
> 
> > Hi,
> >
> > 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.
> 
> In general I'd expect a different approach for embedded Linux. Evaluate
> which processes benefit from KSM and only enable it for these processes.
> On embedded platforms CPU is generally a scarce resource.

Generally speaking, the ksmd at the default scanning frequency consumes
very little CPU and has a low scheduling priority (the value of nice is 5).
And the global deployment of KSM is quite common on some embedded operating
systems, such as Android 13 and its lower versions.

In addition, the feature of controlling KSM by pid has the following usecases
that I can think up:

1) On the OS with a global deployment of KSM, we can dynamically disable the
   KSM-merging of some latency-sensitive processes by PID, to prevent the
   increased COW delay from KSM. Latency-sensitive applications are common
   in a variety of industrial control scenarios or wireless communication
   scenarios (like 5G).

2) Under the new prctl implementing of KSM, the running user processes don't
   have to be restarted if they want to enable KSM, which will be very nice
   and user-friendly to some critical applications that can not be allowed
   to be restart.

> 
> In addition there is already the KSM advisor which checks if VMA's are
> have benefited from KSM sharing or not. If they haven't benefited then
> they are skipped the next time. Have you evaluated this?

Do you mean smart scan? Yes, that feature you mentioned is very good and
improve the efficiency of scanning.

> 
> Simply turning on and off KSM for certain processes seems to be a bit
> questionable. How do you evaluate that you have waited long enough? To
> see the benefits for KSM you need to have at least two full scans. Are
> you taking that into account.

Yes,usually we wait at least two full scan. For some processes, turning
on KSM for certain processes is indeed useful becasue we can see the
saved memory benefit.

> 
> I don't see a strong use case for implementing a second technique to
> achieve something similar.

In a word, the old prctl of KSM is limited and the new implementation of
KSM prctl support the two usecases above, which is very nice and
user-friendly to some critical applications that can not be allowed to be
restart.