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 32211C7EE2D for ; Mon, 27 Feb 2023 19:51:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0E136B0072; Mon, 27 Feb 2023 14:51:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BBDE46B0073; Mon, 27 Feb 2023 14:51:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5FF76B0075; Mon, 27 Feb 2023 14:51:40 -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 94AF46B0072 for ; Mon, 27 Feb 2023 14:51:40 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 49F4EAAFC3 for ; Mon, 27 Feb 2023 19:51:40 +0000 (UTC) X-FDA: 80514116760.11.41309CD Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf28.hostedemail.com (Postfix) with ESMTP id 845B7C000E for ; Mon, 27 Feb 2023 19:51:38 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UypZLlK1; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 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=1677527498; 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=lkevDn4DNYW/8YPDoKxyzBrLj3j2BowCepETKWCJ49o=; b=thxXx9CbHbNLo15wmaLx6ripy4xv6KERRiFPDtUqEbKeaghpSjKITMfTgplWOCgJFsjRbM 8hS/0/hkdC1IAn+z+vNx93kyAKrvptX4nkCqJaCbFfV0MTwHvwPhxg3sfnE5/5zRgY7vx8 IaMx7I/ean3UJcoNHaOxUCHDeYipyAY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UypZLlK1; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 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=1677527498; a=rsa-sha256; cv=none; b=ta7Nnxe5ol0kK970qhP/KUHA+341Ngm7g5SR9rDlpcQUTCJ5q5kWeVB3VDdzeOjrlfHrMZ b4n93eR1J9hioOF4QQdePIUhyQOCRVVeGXa1i9ch04m7jTNve8vz9dB6Xv9+MZW0p1nDhb 4WhhhiKbs6czBeOclxsPZuc6LgY0/R4= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-536b7ffdd34so207571107b3.6 for ; Mon, 27 Feb 2023 11:51:38 -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=lkevDn4DNYW/8YPDoKxyzBrLj3j2BowCepETKWCJ49o=; b=UypZLlK1wJzxwH10S2jYJInQ/vksgV4BR5VhyVRAxNqheIAftXCyONMXMn37xBwePM cwvjJtCiICsIwhkivabN8qCRWuPpVdSL/7Jy0O3ClAhfZoBtsoYDN3iLym4ifR9xOzox d0jSp5W5mbZ1pBmgbMOBTcBPOktUfd4rQD7XI3QNKy/Ap1fSN/itCFXsXVMqfmljHtMS 2+whgIWL6PbW3mUjIbGhnJv/fBq0QKi8ORQSAxNNCvq1Mc2UyQfi4aGQGQIX1OEaX1WW gVTjaAuZJlL13Qf2nk3+kc2Y4W5yUx2e3wPaO9wpGJFmap/MvQWhC4w2/7DbInmojsg7 6vJw== 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=lkevDn4DNYW/8YPDoKxyzBrLj3j2BowCepETKWCJ49o=; b=q3ATdZBCoixHP7tJFrmhRecuqeDcMQUumVRXzBaQ/4d8F0NFETmjd3Bn3swDsb7nlj SwwR1gMmvIli9YJ+bDxzT56oG86v+WW8LQ6iKjzidZeCdXVb+Y6COyTkQm1auqssDUgt GM3j88ixHH0jmfJdBQtcOCjAzDdylJnp0e4f3xQRBCJwkoUu8hj0G03B/qlOBbcDxDD4 19Zc8/u34UfVWxHJcu6fOdKh5Gs53CP1Jg8cfsRV/0qO+D8auZdaJ0A/Ni4Pha2Z8jmN Nlz4hkpLIe7DUw8amcfZCSnV/RKiX6lxc6wUIf6agxstS538YWHnWoPebtWWeNSbBZTB r6rw== X-Gm-Message-State: AO0yUKX3aLZECYfKlYP4Pu7rqlfajvrDpgvgeq3ki1Yxz4Q+hU2L1x8c gbqfMkcIDdFrDEksBvxIrgX9gWtwH7dENzuUogoXlA== X-Google-Smtp-Source: AK7set//uH0WcoiriDP0FpcwDBut7JGs7sxlL9JhfKEDBs8VuN7dLvEIaK1z0x6s2/pSCipMWNt/Ictwg7WDJiwzcqo= X-Received: by 2002:a81:af52:0:b0:533:9d49:f9c9 with SMTP id x18-20020a81af52000000b005339d49f9c9mr692ywj.0.1677527496927; Mon, 27 Feb 2023 11:51:36 -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: Mon, 27 Feb 2023 11:51:26 -0800 Message-ID: Subject: Re: [PATCH] psi: reduce min window size to 50ms To: Josh Hunt Cc: Michal Hocko , 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: 845B7C000E X-Stat-Signature: oqzrunenje6tpdwnzx56sxcr7j4cqw8f X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677527498-969262 X-HE-Meta: U2FsdGVkX1+kZvc18lRg2LmQ3ovzbqT+b7Emx2rH7vOzU+Onwxd/bYejSIuWkRbYsmgRNUvsdlbu5zzu4kJGw2XW+ZHJl7EIqPt99I1MuOCyE9KRVlaWFjJAHI0qBr2Ba/g6xVlMHC8zelYZi4F8ZzyCz8dkAfGKVpnFO562EE/8F7Ss6vGhTY8Q5WQEyX6yQNISCtoJAyxcuUm7SQCPKixe2S/2LsW88WXCVwUi1AkakBiG2SZNSsoDbcbuElEpBXb4DDe1VhGEd/GUkOAz6QfE5fiHAbld0YXYWuHhXR5sVIalo/p0lHUpTMdSFv4VYjctMC23ukUbQMxvgPsazY6/h7pNf9DlPoRGDREqoj9KXzhcpb4gM/VfB68yby1GjJDY3VLbKUeRjA2aliVV/wFX6x+aECqft3G7efiJm8qIfWDaGNjHg82XshcfzSG+ccMIsZmu3Zo+4m/gxP72XoeDaHXLs2Me63mFdUdK6/ja+0idUgeVVbCy5q+O9yKhkT8UaRp80AwuK0WVgdYJyeKNInnaFma3Zt4ACgbJN08pLBe3Euk1h2NAcTjdqmECARL45ehqZApU0t4/XouzxDbJlI/I6FV/RsOCYFtd3qVY7Bm3epf6IHs/Ocwcc69yX2UMmHyH35qYsHH+TB0pCYW0k/8k5/xK6NbnB1whzLFbZ0g84xbqJzo6SMlDzzaHoOxAJYsaoXKfjGkwuX1/DgcqPVumlFePE3/5GqrY07+ZNtmnLPvTbSCt2ihvKiiaXfsPqp0rtSN6pshmwRvxUvKIhnd6EIjihfOryFFsZzM2rfgYnqZJ3jA+9GGBsJTLPCZxEgn8VG5Eh8WdZpZwQ9Ep9EcJiKWiDTsi6bvdWO1yBA/cMdMGOMmf9usa82DRtSBNmgtkJ5uXIJ3JUNU4gHxxf3n9bZSDjGZ/xGp7ci5SgpsCWAkmcg4MbwXoi1Xmxul6YU2pZ7rOqRVwOlD vwc8qZC0 wyylDuE84kKPYMqJ8lb1h57uIb4ldl5tvSrZdXmuxde/GOLfyHDYNvyE94AFnYU7Hk/JrniMTLX9UTYbdi1DiBsBGKkMz+UI1GE0QuqicZLQ+7KiVIVlBtECZDh5FaY8TAcYyxuD4rwcVJrIGWZMPRwXitbQbtjTXcTn20Ul4uRYXdiMzzmB9SeI879/IBbQOIVuwhItAcO4k+GgOj367VF34w9tT5sWcxBQJo9BWKgIeUVNSNOS1dxy/RVlY65NsFtdMCiUOclelqVJVkTOObQEpZALg1ImAOeLkmvMyGNB0266LNsZCA/vMX//0Ifeqi9axN2i/BIz/qeE533DShl0PcW3+c/UVoiljlrZ9Tkyl+y34wsr5EBttkic0u9EoQXxGWhWrJNXDfDneBzWX81+Vw37g5Dwr+HXa8XiTKVIbKGOTxurmw++JZNwGXxQypM+l7H5m7/BNMXJVkBEzeZFDLwniMQTPvlpEUlNlXNyldyslxTml3zftAvdycIPvXkGr7F96xEdg582Tj4armDCH1533zCtfrFuT 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 Mon, Feb 27, 2023 at 11:19 AM Josh Hunt wrote: > > > > On 2/27/23 9:49 AM, Suren Baghdasaryan wrote: > > On Mon, Feb 27, 2023 at 5:34 AM Michal Hocko wrote: > >> > >> On Fri 24-02-23 13:07:57, Suren Baghdasaryan wrote: > >>> 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)? > >> > >> This could break existing userspace which is not privileged. I would > >> just go with CAP_SYS_NICE or similar with small (sub min) timeouts. > > > > Yeah, that's what I meant. /proc/pressure/* files already check for > > CAP_SYS_RESOURCE > > (https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/kernel/sched/psi.c*L1440__;Iw!!GjvTz_vk!WtI61poYlZk9kg5P1sX19RdYnUNGvBJRjnOpu8hL6IOZ_NKhuw2qZ_tAdNRwzZoQVlO4jEObYN6x$ ) > > but per-cgroup pressure files do not have this check. I think the > > original patch which added this check > > (https://urldefense.com/v3/__https://lore.kernel.org/all/20210402025833.27599-1-johunt@akamai.com/__;!!GjvTz_vk!WtI61poYlZk9kg5P1sX19RdYnUNGvBJRjnOpu8hL6IOZ_NKhuw2qZ_tAdNRwzZoQVlO4jAVqIVDv$ ) > > missed the cgroup ones. This should be easy to add but I wonder if > > that was left that way intentionally. > > > > CC'ing the author. Josh, Johannes is that inconsistency between system > > pressure files and cgroup-specific ones intentional? Can we change > > them all to check for CAP_SYS_RESOURCE? > > No, this was just an oversight in the original patch at least from my > end, and did not come up during code review. Fine with me to change them > all to use CAP_SYS_RESOURCE. Thanks for the confirmation! Will get this fixed. > > Josh > > > > >> > >>>> 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. > >> > >> Yes, and why that would be a problem? > > > > If unprivileged processes are allowed to add new triggers then a > > malicious process can add a bad trigger and affect other legit > > processes. That sounds like a problem to me. > > Thanks, > > Suren. > > > >> -- > >> Michal Hocko > >> SUSE Labs