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 6BC52C6FA8E for ; Fri, 24 Feb 2023 21:08:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB5CC6B0078; Fri, 24 Feb 2023 16:08:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D3FA66B007B; Fri, 24 Feb 2023 16:08:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB8776B007D; Fri, 24 Feb 2023 16:08:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A83B46B0078 for ; Fri, 24 Feb 2023 16:08:11 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7D173806CA for ; Fri, 24 Feb 2023 21:08:11 +0000 (UTC) X-FDA: 80503423182.06.D7D8757 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf04.hostedemail.com (Postfix) with ESMTP id C7E7940017 for ; Fri, 24 Feb 2023 21:08:09 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=J2qtqCA+; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 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=1677272889; 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=r9wbtuNWxleLVb+yv1W4YJD99O7SwvhETxSj/pnC9ng=; b=G8303v+l4O6CHp5meP3Fq4g1OgeVzc1RUA+63fCj2VLMYRuVabvDDpztz+97CgtroEhglB u25aM/tOvYKuvKwtEmvJeC4DSmvBZWB3VVZ5b39lQOkVL7qLUM2+Qz44o6smih5iN7gyXh XBREmy7nyvg6ECzDIVvqYSt4UyrHL0s= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=J2qtqCA+; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 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=1677272889; a=rsa-sha256; cv=none; b=AO+udnAoI17VMyo2M5vqwY7ZBPMNNvOXe/i8g1bGL+eL99RRL5erHq77Y0QotHFUbgECgs PUDowWgYa9oEgifC2wqP4PxNZx7YIGOA9muEyd3jFAaUbFl5ZJpFOkuKsqV+/Jsx3bA++s EByFEqE8nAZRHMG4gY+VQo6WdJIAWbs= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-536b7ffdd34so13590327b3.6 for ; Fri, 24 Feb 2023 13:08:09 -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=r9wbtuNWxleLVb+yv1W4YJD99O7SwvhETxSj/pnC9ng=; b=J2qtqCA+5ZQmTHiIw8vCilrIMysrXV71zTJEb0wTKP0wM2N2WmTk9VbR3vxbfYjajU K/oT6b4/lND/oZwRwipH8gwwMVb9TFX8FxZ3+MzAE4r5nSaNUF6UdlAYzzvjs+I6kJtI oNOMHUvJjfnB5BnSlyy9eQqSX9RuVCRWcZh9fRD2a0tc4hTDXmPnB7tr81DDD+3smuH/ lHI+NeRXzVqDvCbvtXwd2s37musw4zKP8F7e91pjhs7eyT3ha+3dUEewcUOZmDpswchE Ogag6IEK2YmR/ugdKYJkKe6Oqj5Xwo+CMac30zuu6jVj9kl0DKZ6XNjNPal/nF5U42pg Nh2w== 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=r9wbtuNWxleLVb+yv1W4YJD99O7SwvhETxSj/pnC9ng=; b=wfDKzKWHIdb6QDOf9I8VGpzer+1DbFrNLhj1N0FpH88QZhq0hgIPj3yuePS+3aQRbF Qp/aFugFX/ChBPgCS/z0keIlDWEJTMZYCd9tBwi+85VEs7pyPOyrFqzHgVYz3RuNCHLJ msQ+u2ItS+WHWys8afOuaa0mfntlkmgXLq7K7NIAsaDa5nvscQu6aIh8Zhyr48RVtTQn 6INRmpsZS0A2Dv9xpUbC5JrZONME8whB/Myx52Qw1vhlnunwSiWYJBNs8JWlgRCDJXZO qOzJBVUunEn2p87lBmSQyhM1JzIrfLTE8lwGWHHr5EEmfQT00gZ1mc6RghwgiNYKBHwJ 2khw== X-Gm-Message-State: AO0yUKUMAev/QvBMvuRzjMBOQWVofNslfb+d3+WRBZLRUkCxChe1Ks7F rVMZW5W6o4RKVoXkbTGshBzPMajJ4SwuBbsNULeDyQ== X-Google-Smtp-Source: AK7set/R8z3TkKd/DLEGjmQ4A1pJVjHZYBqwBiRWEVXdVQUwRn8oZNnugQOi7mX79ntQNFM+TZ3lv4pm0awpGiW/ApU= X-Received: by 2002:a5b:10d:0:b0:a30:38fb:a2e4 with SMTP id 13-20020a5b010d000000b00a3038fba2e4mr3033930ybx.6.1677272888751; Fri, 24 Feb 2023 13:08:08 -0800 (PST) MIME-Version: 1.0 References: <15cd8816-b474-0535-d854-41982d3bbe5c@quicinc.com> <82406da2-799e-f0b4-bce0-7d47486030d4@quicinc.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 24 Feb 2023 13:07:57 -0800 Message-ID: Subject: Re: [PATCH] psi: reduce min window size to 50ms To: Michal Hocko Cc: Sudarshan Rajagopalan , 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-Rspamd-Queue-Id: C7E7940017 X-Stat-Signature: 543ooawd35p8r6jqetm87xib3fqtcpxi X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677272889-405906 X-HE-Meta: U2FsdGVkX1/KPpifKA4JljVTx6lucF0Sbd/LHC7wPMAXxCDBDayZFgzPyBQfnd4cDGqAuipUG8qkUikqjpD7V/PwZp/cP1gxZQrCNIitoL3Mad1hqNwl5aKYor6F0c1C5nq2teS9tc8nxgcFZ98DKyTT+6DzYag6H8cjxTy0YaZ9oXtI2avgFUej4zOsqK9GMDp8IEr8hR/ruFNxzjd0LdNUJurQ4NRUF/R8ANvlTXf4/feXGen6iz7hEEb8TERHOTWyGBv+tmiEixLSaVRnSEdlMivHijdVvU0pfWDqzerpY8fitL9kd+k6GeQrxFqa9ge/dVHW6URhMvOH8WF+6RzOMnQnoRehR2siqyxASfrNVDbgkvuFtDJlQfb2KdsKaxTjvDczHp3Um1sw/vFIa12+2ZUu3pv2kzBh6rUzGvzyJqvVYjsnopKTdJgyPcCoNQU45XTe7wcwPgeVwnmj7xWU+7g39o1KMVIQvktckNsaPQQHdhrJEtSGPBSF7gxf9gw8C/2vnbqhtZznKQWmXadiNR3jvitRhtFYZ8ZlvspkdUji6G7T5Bzr+ZqZcnOs6NJ0YEraVM/rb3qwp9NVYZOgg4uVTTAwskW0hw66juL5A7bAUIBOVxkZ6V2mxWbGXfVad5QY1+B3km9GIKPfhiDGpbeP+4grYdbQdzb8AtjU46RiggVzY1hA94+tal7Aarzds1YCeo/OXnuoUW4NFY703m0yCySUStExJI6nm6Rxdp8qd/UFVlIKWjjW2ONGN9wZRjQRVVb6RtiGy6iR6TZ8cNqgb6JqqCofDRM/mDOZBmSpnEyEbgP9kFeRQWBUEJK8KMCUIZsnOp1JhpBWvxRNj/S+ZDQsdD1BHhA4fJ3BzsgN/zh1ALkaqPf+eHbw2epyw1ZkI3X5O2fiyQAauY9pM8BesmUqFLpWSNInMJH0aIW6YjjNFmVWUHCnH4CIzWJHPNOc1U2QRx3FPUg OUmSCdv6 myJQWAIp5wshGUC6eriWYaKKaW9MXnppcvbSShPdwlUp06G+D9osGAvrQkPQcTnofr5LejzLKVewXsiaUMbMq2bZUnFhGS0WHPG837zkhmolTvBTd5F79ESPfNYmkaMtb5tVDt3TBulglGlYvzTh81PZpDuryumsuLDmec0aSzKgTR8Y+S6MEK4OguXh61r/Uo4jBC+Ui3QrxCvAwYFKiGRJp8H3V9bFdkGNxtvzCzCX6Km21gJbWNOfhcPuhfEGTFYoAU6o7RpPqbrERnp4kAv8d+Z0rHi2Gab1xNG+3sdnixPY+Yc1K7VE6ew== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 24, 2023 at 4:47 AM Michal Hocko wrote: > > On Tue 14-02-23 11:34:30, Suren Baghdasaryan wrote: > [...] > > Your suggestion to have this limit configurable sounds like obvious > > solution. I would like to get some opinions from other maintainers. > > Johannes, WDYT? CC'ing Michal to chime in as well since this is mostly > > related to memory stalls. > > I do not think that making this configurable helps much. Many users will > be bound to distribution config and also it would be hard to experiment > with a recompile cycle every time. This seems just too impractical. > > Is there any reason why we shouldn't allow any timeout? Shorter > timeouts could be restricted to a priviledged context to avoid an easy > way to swamp system by too frequent polling. Hmm, ok. Maybe then we just ensure that only privileged users can set triggers and remove the min limit (use a >0 check)? > > Btw. it seems that there is is only a limit on a single trigger per fd > but no limits per user so it doesn't sound too hard to end up with too > much polling even with a larger timeouts. To me it seems like we need to > contain the polling thread to be bound by the cpu controller. Hmm. We have one "psimon" thread per cgroup (+1 system-level one) and poll_min_period for each thread is chosen as the min() of polling periods between triggers created in that group. So, a bad trigger that causes overly aggressive polling and polling thread being throttled, might affect other triggers in that cgroup. I would prefer to deny creation of a new trigger if it would cause too much polling. However, that seems to be getting into the territory of "implementing policy inside the kernel". Maybe we just limit trigger creation to privileged processes only and let those privileged system components worry about trigger creation policies? These system processes can also limit cpu shares of all "psimon" threads using cpu controller, if desired. WDYT? > -- > Michal Hocko > SUSE Labs