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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EA62C7EE2D for ; Mon, 27 Feb 2023 19:11:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229943AbjB0TLP (ORCPT ); Mon, 27 Feb 2023 14:11:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229703AbjB0TLN (ORCPT ); Mon, 27 Feb 2023 14:11:13 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 151DF2412A; Mon, 27 Feb 2023 11:11:10 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B206C219F8; Mon, 27 Feb 2023 19:11:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1677525068; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=k7KLqc0ddMXLeQzmWAODibPhNefuYjs5GZ/oLOoQbho=; b=EWgOdMt9uLzuqoPUeB79LOuBCUrHjFTtVdJQ5hYBnMXNvMVzAbI98b3A6VjBIftUaWTooM loUS2WCJYIvxXGxxbSqEkzoAdmgyMt343VMkKJepTyaE+bjL60uiM7N+tAR9fu4YnE8KXZ mV62PV9lxoztijjx1ZaOzygRFLz9LBE= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8FB1413A43; Mon, 27 Feb 2023 19:11:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id CzbTIEwA/WNcDAAAMHmgww (envelope-from ); Mon, 27 Feb 2023 19:11:08 +0000 Date: Mon, 27 Feb 2023 20:11:07 +0100 From: Michal Hocko To: Suren Baghdasaryan 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 , johunt@akamai.com Subject: Re: [PATCH] psi: reduce min window size to 50ms Message-ID: References: <15cd8816-b474-0535-d854-41982d3bbe5c@quicinc.com> <82406da2-799e-f0b4-bce0-7d47486030d4@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 27-02-23 09:49:59, 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: [...] > > > > 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. Hmm, I am not sure we are on the same page. My argument was that the monitoring kernel thread should be bound by the same cpu controller so even if it was excessive it would be bound to the cgroup constrains. -- Michal Hocko SUSE Labs