From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3840FC636D4 for ; Sat, 11 Feb 2023 01:09:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE38C6B007D; Fri, 10 Feb 2023 20:09:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A903C6B007E; Fri, 10 Feb 2023 20:09:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 931076B0080; Fri, 10 Feb 2023 20:09:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 81E106B007D for ; Fri, 10 Feb 2023 20:09:55 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4D9DB412DC for ; Sat, 11 Feb 2023 01:09:55 +0000 (UTC) X-FDA: 80453229150.13.652FA80 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf30.hostedemail.com (Postfix) with ESMTP id 7BD5980002 for ; Sat, 11 Feb 2023 01:09:52 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WekWIQLe; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676077792; a=rsa-sha256; cv=none; b=FqaiUacjLrdllow3SXKFvdsA3SnSYfVA4iP5lSUkiM4TIaw9kTM1D2h0rwigP1+MTcIYBl 4UX480jp67K8AeJ7JsjxEaEBJcpOg9EQ84MNtfaHYRYNOZRYGX+gTAgiBHC9tI1ys0fNme oT4E+ZD/sfzsiFxE56c/GgvEid2UOyo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WekWIQLe; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676077792; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XC3OE2iIqVJFJ6R0Eeu5KTHfFtnBegsFQuYmWX1hk7k=; b=zkLBViZi8bCS631zi7QJqQv6iQVkG74XyyBN90aqZwt1K54sdFqe/D71k6WHTLYU7noBC+ uigcIB5zQqeJBorVx+q606VY47mdMtFend8eoorMx+woPSWiKVwHe8P8GkZXHRIQQiyyK7 gw47WsYNWpnTNmWsMLCzRQdY69+5yGc= Received: by mail-yb1-f175.google.com with SMTP id g2so8358522ybk.8 for ; Fri, 10 Feb 2023 17:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XC3OE2iIqVJFJ6R0Eeu5KTHfFtnBegsFQuYmWX1hk7k=; b=WekWIQLebF5KjrFfzL8IcbO4+JZy6ZTRBje7mB4hTEercvPXDs0HjJ+tCvMgxlKsMS WnlrJFkdf1rOzOfaQDdPz2yELe89ntq/wJZzq0OFkKJlY1aTEXPBagAEfzRw1mY+XfFg sR7QEwFWFOC9zD/WFnJjqxSiQsHggFV+O/TqncTm4NvBUjiYIyaaC9yDsqx2yC5s/l4M 2ezg6B1Y7o4qnUAsRaX4fzSAJwc+Dz05oHKaj8mv5dXuYCLs9vHK9RDK3jxmgqyTqLGT 0o2TyxiQUeskMviKmnS9lql8kPR7SWsWKGWjFtE2hBy4wxOfKrnbmYJ6g2S83sooDUb7 aypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XC3OE2iIqVJFJ6R0Eeu5KTHfFtnBegsFQuYmWX1hk7k=; b=Yrb+adfXh+bhIIMks64HkNQ2utKv6pDR2ZEbBanUQPX9n8DuTVM9Wp5V4lcdXIiUCA DXqYmjySeZE5Ou69IhiZWxyfjgo6ACylKBLOru5YQSYTsByL9PXzxgTJtN8s0WVjGISf iHOarPoX7nJVxIFPMvzdpW4uzXoaug+FkfAOrFrw0q3ENS6XwaMrz1dlwSpAriMfOlTo RlwUD9ZVpIin6Qyy68pN7mA5DpsF3jrtZsU5MoF064UrCZOSAv6fODMe+k6QGHVIYXxD zbjCWVIom8Ne26aAk5wFF/Vmi9prR4Z+Nc7QiRyZsgo5ZTqEOJKukbK4fruwcey61OpB gXMg== X-Gm-Message-State: AO0yUKV3ZRh0Oa+4MogNd/qHL/2cFs3m84gkoAAGTCKpmpq2nJ8a5xzb V8h9fABKRh2R1pvv1fqwzsXXM0vb57jyYoUEhs+rpw== X-Google-Smtp-Source: AK7set8UGTKsm+YOX8AAw4yvHGBGAaHjkcEpaELI8tgK0Vu08OWZuoQQre5zZiaKBjzuQCUIbW3rptH8tMwm8JpsiR0= X-Received: by 2002:a5b:707:0:b0:8bc:56a2:49d8 with SMTP id g7-20020a5b0707000000b008bc56a249d8mr1095067ybq.428.1676077791362; Fri, 10 Feb 2023 17:09:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Fri, 10 Feb 2023 17:09:40 -0800 Message-ID: Subject: Re: [PATCH] psi: reduce min window size to 50ms To: Sudarshan Rajagopalan Cc: David Hildenbrand , Johannes Weiner , Mike Rapoport , Oscar Salvador , Anshuman Khandual , mark.rutland@arm.com, will@kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, Trilok Soni , Sukadev Bhattiprolu , Srivatsa Vaddagiri , Patrick Daly Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 7BD5980002 X-Rspamd-Server: rspam01 X-Stat-Signature: hamhzaqus5tn1q5dtwi9ojo4s6uybger X-HE-Tag: 1676077792-993850 X-HE-Meta: U2FsdGVkX1+6ZqouE1QcE4j2ijx12T0blDcupa2H6bE8SUNJEXbdzOa6kTqz4/2KgXsnrNp1coU3UWOo06Pnqm2HHlwTNnilVxpWi1TtrF5B2dseavdWX5mhccHiMUFdL5YbKwElbUj0q2Ibd0PmjIAbxkJxBjCaA3S0ZEs4Uz1x40er1PtA0vH+dgwMv/lZJXUv8mGDbGSqV+IGdxS3oZVe/0jtneVuLSja/zzC0h/Z4Nkf9JdX66UEL+/kfYFVx2OwnIfUrUnvu4+YPWIrlfj73Bl7YJHyrRB1eDmAf7YVTm2eZavsWYnEBaod7EYXy35vwFVfv5A/lgXfTZwqW0HkCkVb/R5iEzz40CvZS9QUSew9QYRGYA24Seylzb0Oy3vOHlnOpZo3KOhrjmpPmBy6osYOU+jIgrR7+3gwPztuVNghKGKuralHAPS7Nw6Q7mq/oHOGwubZT2XnBAGuI1gRevm+3xecppmYoA2WqvRma2hyN6KUz8U1IaY0U2jDwiJh74wKB4Kxc+hzl/BCmnOY6iYNm3lDPirC0HcunJrbjqZZ1aSakEpdpr9Ajvdz4NL9n4m+/fWZGWtgXE/pFwqciCljNCZLi9KxQ59/tVwE5kp2bw127Q8b6/7UZoFFyB6R15VIn+U9FFYys9rHPHInadVdXWPWK4ptzrZYdeVBs/SidBsoAqL0XzPm3CxbEWbzztcVSuMagSHscaW3kUnFEB6MKA/x08tDwp/1Ko+3HVtgwYwU0R2B3xkisCcZiTRgKOMAtGdaUU8ILrBfOHUHoXS7UMjWF+ZjK27amna51feWU/DJ8n3wmEn73yj4h6QEOQvgXS+kgUon/IyqoagzxyZzU5BVxDIyAf9gqgJbfJ/mf3PNpeEjDqi7skt/pVFFrhHBaMLZQniSC80tjbw8q6MSo1pE+eHT73q0L6DBCm6Zyammj70nTIL0Z4fiLYuH2bAJ2aXqKcsvaCd MLo5j7f7 fQVAjmzTW2LxlDhHjC2akCu4uVNEMzaeGm169e8WleYWjtSAsAvIm3GRmKBZTx3QNLCNDIJKEFMqwYqSP5g0AwmRdBTrnf2WI6C6EnpCsP8mjGH1QY9DzHq2WsIL4LHVDrtLsMLKmWhcJEVZbFcqCipWsQQwGzKwPvU3BI3vrE2YGdhsudpQf5BIyA5ix3b0U+Y6UhXKJTxO7BMp/tydRW/dFYE6fETVaikuLtRk9YQodEo+r6YuE/LMILUuXrUDudMvzJyvaU8Kg/bgsMqlXLtWibzICRn6xip4+j1OlhT1qk2ZIOov4SmpDInolectYObEsdHIhWVNpwrdCLQeZ0ONrR+BJME8NlRt4M8Qa0JGef2i+rJ6+R2SRluCCaUriYtc2 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000964, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 10, 2023 at 4:45 PM Sudarshan Rajagopalan wrote: > > > On 2/10/2023 3:03 PM, Suren Baghdasaryan wrote: > > On Fri, Feb 10, 2023 at 2:31 PM Sudarshan Rajagopalan > > 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@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 > >>