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 CC93BC4332F for ; Wed, 12 Oct 2022 06:20:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 059066B0071; Wed, 12 Oct 2022 02:20:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0087E6B0073; Wed, 12 Oct 2022 02:20:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E39F46B0074; Wed, 12 Oct 2022 02:20:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CF6C36B0071 for ; Wed, 12 Oct 2022 02:20:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9ED014042A for ; Wed, 12 Oct 2022 06:20:51 +0000 (UTC) X-FDA: 80011299102.26.67B2A9E Received: from r3-11.sinamail.sina.com.cn (r3-11.sinamail.sina.com.cn [202.108.3.11]) by imf13.hostedemail.com (Postfix) with ESMTP id 5445B2002B for ; Wed, 12 Oct 2022 06:20:48 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.60.223]) by sina.com (172.16.97.27) with ESMTP id 63465C8800001B96; Wed, 12 Oct 2022 14:19:54 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 22057549283676 From: Hillf Danton To: Suren Baghdasaryan Cc: Pavan Kondeti , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, quic_charante@quicinc.com Subject: Re: PSI idle-shutoff Date: Wed, 12 Oct 2022 14:20:34 +0800 Message-Id: <20221012062034.486-1-hdanton@sina.com> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665555651; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lEb4Fa8CadTmzDh5GMatDtTK9pk0uhgq7SHluhAKCUE=; b=bPCKzhamfQb7hYlYl5HVteWMTKt/1ADJOf+aa3izWZZai50OGX2z0iUOuZhdolPNJ5p6jE o9Y0BNh5+2HEgOGoNkm9+MnB7ZBAW7vEol7STFgpn2/0i1XZeofajFutXJ39dkyaqETvGM JYvTrnxmuv6bqA0O438ay7iZpuQb9Rc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.11 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665555651; a=rsa-sha256; cv=none; b=gzsOZJ6Pd+on1ZJsD+8raeldvK9Hi5RJ7cM9FAi50UCc3MaXPAAqecjmJFidmqMXP6SgJk 8aOFMB0M4sZgea96CI0dsq0uoiG1S7x4Mdl6sZTM0tPnNeXEV9EpAAo4zDpkXdfwwup4EM gBDw5CIbT3BfWSxf9hEBY5U60I/1aek= X-Rspam-User: X-Rspamd-Queue-Id: 5445B2002B X-Stat-Signature: j51pf7zhwj3dorzsa1onw9ec11jajcyg Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.11 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam10 X-HE-Tag: 1665555648-428983 X-Bogosity: Ham, tests=bogofilter, spamicity=0.015651, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11 Oct 2022 10:11:58 -0700 Suren Baghdasaryan >On Tue, Oct 11, 2022 at 4:38 AM Hillf Danton wrote: >> >> Given activities on remote CPUs, can you specify what prevents psi_avgs_work >> from being scheduled on remote CPUs if for example the local CPU has been >> idle for a second? > > I'm not a scheduler expert but I can imagine some work that finished > running on a big core A and generated some activity since the last > time psi_avgs_work executed. With no other activity the next > psi_avgs_work could be scheduled on a small core B to conserve power. Given core A and B, nothing prevents. > There might be other cases involving cpuset limitation changes or cpu > offlining but I didn't think too hard about these. The bottom line, I > don't think we should be designing mechanisms which rely on > assumptions about how tasks will be scheduled. Even if these The tasks here makes me guess that we are on different pages - scheduling work has little to do with how tasks are scheduled, and is no more than queuing work on the system_wq in the case of psi_avgs_work, > assumptions are correct today they might change in the future and > things will break in unexpected places. with nothing assumed.