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] [thread-next>] [day] [month] [year] [list]
Message-ID: <e944536f-a04c-5528-601e-d7f505a761e8@quicinc.com>
Date:   Fri, 10 Feb 2023 16:44:57 -0800
From:   Sudarshan Rajagopalan <quic_sudaraja@...cinc.com>
To:     Suren Baghdasaryan <surenb@...gle.com>
CC:     David Hildenbrand <david@...hat.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Mike Rapoport <rppt@...nel.org>,
        Oscar Salvador <osalvador@...e.de>,
        Anshuman Khandual <anshuman.khandual@....com>,
        <mark.rutland@....com>, <will@...nel.org>,
        <virtualization@...ts.linux-foundation.org>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-arm-msm@...r.kernel.org>,
        Trilok Soni <quic_tsoni@...cinc.com>,
        Sukadev Bhattiprolu <quic_sukadev@...cinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
        Patrick Daly <quic_pdaly@...cinc.com>,
        "Sudarshan Rajagopalan" <quic_sudaraja@...cinc.com>
Subject: Re: [PATCH] psi: reduce min window size to 50ms


On 2/10/2023 3:03 PM, Suren Baghdasaryan wrote:
> On Fri, Feb 10, 2023 at 2:31 PM Sudarshan Rajagopalan
> <quic_sudaraja@...cinc.com> wrote:
>> The PSI mechanism is useful tool to monitor pressure stall
>> information in the system. Currently, the minimum window size
>> is set to 500ms. May we know what is the rationale for this?
> The limit was set to avoid regressions in performance and power
> consumption if the window is set too small and the system ends up
> polling too frequently. That said, the limit was chosen based on
> results of specific experiments which might not represent all

Rightly as you said, the effect on power and performance depends on type 
of the system - embedded systems, or Android mobile, or commercial VMs 
or servers. With higher PSI sampling, it may not be much of power impact 
to embedded systems with low-tier chipsets or performance impact to 
powerful servers.

> usecases. If you want to change this limit, you would need to describe
> why the new limit is inherently better than the current one (why not
> higher, why not lower).

This is in regards to the userspace daemon [1] that we are working on, 
that dynamically resizes the VM memory based on PSI memory pressure 
events. With current min window size of 500ms, the PSI monitor sampling 
period would be 50ms. So to detect increase in memory demand in system 
and plug-in memory into VM when pressure goes up, the minimum time the 
process needs to stall for is 50ms before a event can be generated and 
sent out to userspace and the daemon can do actions.

This again I'm talking w.r.t. lightweight embedded systems, where even 
background kswapd/kcompd (which I'm calling it as natural memory 
pressure) in the system would be less than 5-10ms stall. So any stall 
more than 5-10ms would "hint" us that a memory consuming usecase has 
ranB  and memory may need to be plugged in.

So in these cases, having as low as 5ms psimon sampling time would give 
us faster reaction time and daemon can be responsive more quickly. In 
general, this will reduce the malloc latencies significantly.

Pasting here the same excerpt I mentioned in [1].

"

4. Detecting increase in memory demand b.. when a certain usecase starts
in VM that does memory allocations, it will stall causing PSI mechanism
to generate a memory pressure event to userspace. To simply put, when
pressure increases certain set threshold, it can make educated guess
that a memory requiring usecase has ran and VM system needs memory to be
added.

"

[1] 
https://lore.kernel.org/linux-arm-kernel/1bf30145-22a5-cc46-e583-25053460b105@redhat.com/T/#m95ccf038c568271e759a277a08b8e44e51e8f90b

> Thanks,
> Suren.
>
>> For lightweight systems such as Linux Embedded Systems, PSI
>> can be used to monitor and track memory pressure building up
>> in the system and respond quickly to such memory demands.
>> Example, the Linux Embedded Systems could be a secondary VM
>> system which requests for memory from Primary host. With 500ms
>> window size, the sampling period is 50ms (one-tenth of windwo
>> size). So the minimum amount of time the process needs to stall,
>> so that a PSI event can be generated and actions can be done
>> is 50ms. This reaction time can be much reduced by reducing the
>> sampling time (by reducing window size), so that responses to
>> such memory pressures in system can be serviced much quicker.
>>
>> Please let us know your thoughts on reducing window size to 50ms.
>>
>> Sudarshan Rajagopalan (1):
>>    psi: reduce min window size to 50ms
>>
>>   kernel/sched/psi.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --
>> 2.7.4
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ