On Fri, Feb 10, 2023 at 4:45 PM Sudarshan Rajagopalan <quic_sudaraja@xxxxxxxxxxx> wrote: > > > On 2/10/2023 3:03 PM, Suren Baghdasaryan wrote: > > On Fri, Feb 10, 2023 at 2:31 PM Sudarshan Rajagopalan > > <quic_sudaraja@xxxxxxxxxxx> 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]. My question is: why do you think 5ms is the optimal limit here? I want to avoid a race to the bottom where next time someone can argue that they would like to detect a stall within a lower period than 5ms. Technically the limit can be as small as one wants but at some point I think we should consider the possibility of this being used for a DoS attack. > > " > > 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@xxxxxxxxxx/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 > >>
