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 91A3BC433F5 for ; Tue, 4 Oct 2022 02:29:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDA686B0072; Mon, 3 Oct 2022 22:29:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8B1E6B0073; Mon, 3 Oct 2022 22:29:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2BA96B0074; Mon, 3 Oct 2022 22:29:51 -0400 (EDT) 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 B000E6B0072 for ; Mon, 3 Oct 2022 22:29:51 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 743DDAAAA6 for ; Tue, 4 Oct 2022 02:29:51 +0000 (UTC) X-FDA: 79981686582.29.FC15852 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf09.hostedemail.com (Postfix) with ESMTP id 06A8D140017 for ; Tue, 4 Oct 2022 02:29:50 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id bu25so19177682lfb.3 for ; Mon, 03 Oct 2022 19:29:50 -0700 (PDT) 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; bh=LXc/Zr9rQnUyqTp1Msxz0HMk29xy25iHM+OGOUqnh3g=; b=P+9IwY0lgP4SjANLp/p6iC3wXSkCq1AxDeGJ0pqe4skyVfuFjM1M9zc/uAOrvH2PmB iJtz8uJl+JevvJjA5NF5/ETPwATuYwT2epaVgFLTusaz7g+T9e+TieLroDz6JBlFAX19 Zz8gflffjQws1LnCy66HzYKz6lRkPZIP7kPKmQwax6veEg/svrGogvGXm3ImsfpFBA7c lkAiZgKqdCe6OGwz7402FAi/nrfYc9sPNH1HHLYXQZhUbTQc8M83JO327+AHaCaoM/OA BF4HMUlg5AziqwMl6iN2JAFlr5q0Z2I79K50LcKOxWuzVKSl4b73F3h7lo59z9OcZhy0 tUCQ== 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; bh=LXc/Zr9rQnUyqTp1Msxz0HMk29xy25iHM+OGOUqnh3g=; b=B8rjRC43Lpa9FiRFmE+BXQ0RwyqYp9NY6/AqEd1daSwk4sHKRbXvTTHwH//tzoKnmH eBcVc4QTuiIFb3vq3SiuDTdrG6YonygqojMvA1Hv9ffMNUWM7PZaValfDxUHWMFho89D 42LJoHKME7G12Lwia+rq80ToVRstB/uDLgvSEdGxn2G6PworVoTmJFSZMDm9Po7GT1fW 9qm414z7NqP46p97rtDzeL00sR2ph3pmRlBQvGRX5JsoR6o93EE6uL9hiKbfXosdSoVg sVfDJwCCohI7utnhc4tTxTs62uHJL1DRf2qE2KnP1hzRLO9qn7eM5nRojTXF/bFkDcN6 T3lw== X-Gm-Message-State: ACrzQf1nFlI91HfQpkRNHRP5EQ/r17+HltjT/NBkw1AfAvKMeaDsfOZX fhE6BGz07tifInNXSiHjswLm9uiNnuEO12f7CFQx X-Google-Smtp-Source: AMsMyM7MyIdPOq0gTZwp9zWFUypig2W9uQTQgh+lBOZbwJxsVl+CWr1Rmi+5oWwOAh4ZNeXjxJb6VsA9YrxHWe3gAY0= X-Received: by 2002:a05:6512:33d5:b0:49a:d2dc:e1e3 with SMTP id d21-20020a05651233d500b0049ad2dce1e3mr7608239lfg.628.1664850589042; Mon, 03 Oct 2022 19:29:49 -0700 (PDT) MIME-Version: 1.0 References: <20221003232033.3404802-3-jstultz@google.com> <20221004013611.1822-1-hdanton@sina.com> In-Reply-To: <20221004013611.1822-1-hdanton@sina.com> From: John Stultz Date: Mon, 3 Oct 2022 19:29:36 -0700 Message-ID: Subject: Re: [RFC PATCH v4 2/3] sched: Avoid placing RT threads on cores handling long softirqs To: Hillf Danton Cc: LKML , linux-mm@kvack.org, "Connor O'Brien" , Qais Yousef , Peter Zijlstra , Steven Rostedt Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664850591; 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=LXc/Zr9rQnUyqTp1Msxz0HMk29xy25iHM+OGOUqnh3g=; b=3Jfu7Oe9cGjECwTZVIhVe+gWGy/yJlNEpRuuxj/tGD3IpTabzHAQR+9r8kpVepO74Wth/+ TdkMy6tpc/LWqpgXyJGgqrwtzSCPHne72OaUUQjZPEKW0zfZ1hbump1sSUkORTSIe6ye5z 2X+HZFWxG21C9jG2n5cMQZIFr6vIcA8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=P+9IwY0l; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jstultz@google.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=jstultz@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664850591; a=rsa-sha256; cv=none; b=KSB/O3ob8P8jSlWC012i+WFYjiWFEfqCNPK7P1SEpkw+/xUD+TeVH74EkKBx+UNaIiRRFO z4cb639+Y6KGsrkHcvAQqF4ckwrO42Jdh99vMMosHTxPBrdN+d90goTFPWo5G6pqhNqIgp 5A37jGQLYNn3XcAZlt5lWEm/ejJghnU= X-Stat-Signature: syx1pfqr5d719hc8r6741k5hozhmmy8y X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 06A8D140017 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=P+9IwY0l; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jstultz@google.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=jstultz@google.com X-HE-Tag: 1664850590-941576 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, Oct 3, 2022 at 6:56 PM Hillf Danton wrote: > On 3 Oct 2022 23:20:32 +0000 John Stultz > > +#ifdef CONFIG_RT_SOFTIRQ_OPTIMIZATION > > +#define __use_softirq_opt 1 > > +/* > > + * Return whether the given cpu is currently non-preemptible > > + * while handling a potentially long softirq, or if the current > > + * task is likely to block preemptions soon because it is a > > + * ksoftirq thread that is handling slow softirq. > > + */ > > +static bool cpu_busy_with_softirqs(int cpu) > > +{ > > + u32 softirqs = per_cpu(active_softirqs, cpu) | > > + __cpu_softirq_pending(cpu); > > + struct task_struct *cpu_ksoftirqd = per_cpu(ksoftirqd, cpu); > > + struct task_struct *curr; > > + struct rq *rq = cpu_rq(cpu); > > + int ret; > > + > > + rcu_read_lock(); > > + curr = READ_ONCE(rq->curr); /* unlocked access */ > > + ret = (softirqs & LONG_SOFTIRQ_MASK) && > > + (curr == cpu_ksoftirqd || > > + preempt_count() & SOFTIRQ_MASK); > > + rcu_read_unlock(); > > + return ret; > > +} > > +#else > > +#define __use_softirq_opt 0 > > +static bool cpu_busy_with_softirqs(int cpu) > > +{ > > + return false; > > +} > > +#endif /* CONFIG_RT_SOFTIRQ_OPTIMIZATION */ > > + > > +static bool rt_task_fits_cpu(struct task_struct *p, int cpu) > > +{ > > + return !cpu_busy_with_softirqs(cpu) && rt_task_fits_capacity(p, cpu); > > +} > > On one hand, RT task is not layency sensitive enough if it fails to preempt > ksoftirqd. On the other, deferring softirq to ksoftirqd barely makes sense > in 3/3 if it preempts the current RT task. Apologies, I'm not sure I'm following you here. Why would ksoftirqd preempt the rt task? thanks -john