Re: [PATCH 0/3] mm/ksm: Support controlling KSM with PID

Re: [PATCH 0/3] mm/ksm: Support controlling KSM with PID

[xu xin]

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.

Re: [PATCH 0/3] mm/ksm: Support controlling KSM with PID

[Stefan Roesch]

xu xin <xu.xin.sc@gmail.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.

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?

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.

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

Re: [PATCH 0/3] mm/ksm: Support controlling KSM with PID

[xu xin]

> xu xin <xu.xin.sc@gmail.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.