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 8DFBCC636D4 for ; Sat, 11 Feb 2023 02:13:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1F646B0074; Fri, 10 Feb 2023 21:13:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CCF5C6B0075; Fri, 10 Feb 2023 21:13:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B96D06B0078; Fri, 10 Feb 2023 21:13:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AAB9F6B0074 for ; Fri, 10 Feb 2023 21:13:52 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 710181412D2 for ; Sat, 11 Feb 2023 02:13:52 +0000 (UTC) X-FDA: 80453390304.17.BC6A053 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf18.hostedemail.com (Postfix) with ESMTP id BAFE91C000F for ; Sat, 11 Feb 2023 02:13:50 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NPI837DV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676081630; 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=AVP4LC3gxGWSgfBKADHFIlAxBAsTci144FYv9y485hg=; b=GyfAILHg7kwKzHXNS0oRQ5ZkJySC5D8qFIFd9eXjvDtfo9SCLOeGKQ4qgFfS1/owai5V/n +Fiy5Fu7Pvtdy9LJVved1tzU/8dZimTjdL8/H3SMgRdWcWCWU3CH1z5KX6AeQ3viF9N+J0 CqzmVwvaPSkCcqyrZWdweWfIglbrYLg= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NPI837DV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676081630; a=rsa-sha256; cv=none; b=kRXs3MMkK0KSXnoZ8dnE7AtqLRoEGa+Eug2MS8uPKuCstdfN1OixtZXHEWWoTmDdMLN2w+ Gzr/+cp+L2kPJXQE0PvkVWRGEboLIqOXz57Shm29P0swgggnt8VaWMgqLpHVgtgip23gPC uH0mT1vLthp7KMCNxVYyYzs4OSvEWAo= Received: by mail-yb1-f179.google.com with SMTP id x4so8525465ybp.1 for ; Fri, 10 Feb 2023 18:13:50 -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=AVP4LC3gxGWSgfBKADHFIlAxBAsTci144FYv9y485hg=; b=NPI837DV4EdaoeNJsQeGxGiORVPx5kAQoNueJgiD1XlDEvkL9LVfAu7g3ZGGyS2doo 9Bq1oBX5y/YPpS9ZrpUunYyN+Xf8nMnvZ2NizCyftSOeC5K86feu6z58rTOc/+fowTIQ vhFpdKzZ8TEHx+/CEj1PuP1piN8qezpPEWCjcrLJjkOqDZi4I9ECxLWeilbpYRv9DrbX +2CLc7jkXjeuF4sSaZGeDFLtLIHb3eFqaC5BoEOP4RUEoS8nMtDxR9kByfgXTEtRa7PV qYAcc1DMFmNJX9QkrCx1RTtCFSWIKDVZw7YwjPaB3LKXHZI/2WI82Ahf9j5iT45u0pET /v8A== 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=AVP4LC3gxGWSgfBKADHFIlAxBAsTci144FYv9y485hg=; b=K6fGf6zpwrdOfGzz8XVvPAnWDf6IWqQJHFko189U/Jc80SRo0mDBxZlJiJwUIWoyMG hJYknqTiGLd/M7+po49+cettUD4eFQSsiNDo7osDBjYjdL63XhAxLgl68F6nBAIp90WO Gkup0aFUl7nirsTKtyAXvedFEGvoGiNOwWawlbkVZABXnfD83BpJJZBOgNLKray1Dfhg IZQTbjotgsduSR5GGmCYFSn3XO7cZrk0qJ596YyKgJO8T9OBbqPjr11ubKVj49B97WQI jBb/HrSsTRNuTgYmVK7o6mG+l72Zlwqf1JYlUjLievOMXu+5xAiLV1WgsdwpAp6gmN/i Gt3w== X-Gm-Message-State: AO0yUKU0omo4dkTFYSgvqwRenaySqC9ZeRuxh3IhAE3tgd/LC7lCbXbr PrQrhAdE6uaU9wWUuAiWC+PvyZPGs26/DVlXmOJBmQ== X-Google-Smtp-Source: AK7set+3gfrSyBe2ekI0j3jHxJx6O06Jkj6lGbli3p2gDEex73DfaLxJS9IdJnjitOuP+Gh+sLvcheeC4VLot30O7pM= X-Received: by 2002:a25:eb0f:0:b0:8ef:c897:33aa with SMTP id d15-20020a25eb0f000000b008efc89733aamr373455ybs.288.1676081629619; Fri, 10 Feb 2023 18:13:49 -0800 (PST) MIME-Version: 1.0 References: <15cd8816-b474-0535-d854-41982d3bbe5c@quicinc.com> In-Reply-To: <15cd8816-b474-0535-d854-41982d3bbe5c@quicinc.com> From: Suren Baghdasaryan Date: Fri, 10 Feb 2023 18:13:38 -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-Server: rspam02 X-Rspamd-Queue-Id: BAFE91C000F X-Stat-Signature: e8bxpr3oij9c8sco11hkopn9k6pogizp X-HE-Tag: 1676081630-933795 X-HE-Meta: U2FsdGVkX1+dNGYyDfQLkZwqb3pdC7d8WxjHh1xGb1M5yCMBivhgZDQwYRurON3LPbyHqfo/VphNPJBcsavnSZLkcnOelm5o/oIfWVUd3cC9mkEVyPVJhhKCEV1a7+9fkF4ZAKLoIIY3hQLWO/s/ZNbObM7h5J6PSOagss7ne0VJ6+5F/mJicYuJqxrlXLzjveK3GYd/mLPYp9BXaF6L3MBZzHXKmi9wCorVh8Dfi7goMgGi9F9urXSXM2Ss26wGPS6gcrtjM6tK5MUq47o4IX7HA+sGlIZEDVN5WVtZKDKlrigUVrU8ZwJLeYmPDdwyVYBRnpt+tmubR8JzXk4PYKIkZBVGqSvDdQXzelTc0McJssuBIoiR6gxPypC1CUIah1XhGDAXUCd4/wI8yDTa3tQwtpLOZrKhsPt8uRhSYWHdUIKZ6IxqnynzFG+gp74PLVtUgpVgUKwLYvIRURcxUcqXIhsU772xzMiLwdFdOPR0AcwfZaDen+BTN8bVP5/DTCJn0Fz22yQcl0yOG5l7NmFJzygdTL1/+AkFhp48CEeM09tzEApS4ujM32KlYQAZDuo4uIcm2piKzgUbr/jxulhGvxCgqTN0r1wDUqC4uLBfE1ieTR1HbMrJ169g74Y3qMlHJqJLRYPb3irVLGqQdp1tC05HvJACrblUwFBjusqq4YtdQs3gcMlIeK923z/lJuhoJrAmsTkRFUkAFE3xav+E9j4fuOQlNSsut3Ogk7jC0opbxlbThRkUp+Im9F3J9WMNNAbwc3GL45POiJriI5/FLHaRpO/jGrT06Z6Zu4EX3OPBjvMiZSxcH1xXGP7H6TaDbQDXhC8lKco+iuByuhAZFw5O4hAzi1i51zoiF9n2klmOstRHPmVBwUKu8VYr6BCD1BCFbAXXY6OAIvi+GqptnmqbgGHWcs/SXKznZIfB3x3o5ltcddsDucljKwdSVywMtqU6gvgV9vsfZdP 8kntcsnA lvfimIlbGpHEMPtPVJJlBVa5xDmzEeBs76O4IPAYcgsTEQIsDKk5FtownlDwnZaHgDXes4ePrZ/cIVapjzBH0RseFgiKcpZX2TVplZ1y+YHi/3A6ckKRmnO7zy2/IUYJdgjPJy91VpyJ/emZ15cJE0M1h5S7HDvLcwe8wa3r52or/bgRsz2ICKuMOx9HrtfPflfL1S7YXk7CPrGgcnfFypOB6FgEl8ObOQDkAq7J+43JtTJRBxVkQa+/6CmaDDdvC3H0QQyZ9yUt3QFT/lOVEXZAsKzIzq9+2WuvgKZjacq8lwB12I5MV0O8XsJrPvjirm2htkhYSLxat/XMNJ1EkO8coudfxtkaUb4fFnAMhwQGGomgT0AcFo4wduMwwT0TkpE6L X-Bogosity: Ham, tests=bogofilter, spamicity=0.001150, 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 5:46 PM Sudarshan Rajagopalan wrote: > > > On 2/10/2023 5:09 PM, Suren Baghdasaryan wrote: > > 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. > > Well the optimal limit should be something which is least destructive? I > do understand about possibility of DoS attacks, but wouldn't that still > be possible with 500ms window today? Which will atleast be 1/10th less > severe compared to 50ms window. The way I see it is - min pressure > sampling should be such that even the least pressure stall which we > think is significant should be captured (this could be 5ms or 50ms at > present) while balancing the power and performance impact across all > usecases. > > At present, Android's LMKD sets 1000ms as window for which it considers > 100ms sampling to be significant. And here, with psi_daemon usecase we > are saying 5ms sampling would be significant. So there's no actual > optimal limit, but we must limit as much possible without effecting > power or performance as a whole. Also, this is just the "minimum > allowable" window, and system admins can configure it as per the system > type/requirement. Ok, let me ask you another way which might be more productive. What caused you to choose 5ms as the time you care to react to a stall buildup? > > Also, about possible DoS attacks - file permissions for > /proc/pressure/... can be set such that not any random user can register > to psi events right? True. We have a CAP_SYS_RESOURCE check for the writers of these files. > > > > >> " > >> > >> 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 > >>>>