Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp185199ybz; Tue, 21 Apr 2020 07:11:06 -0700 (PDT) X-Google-Smtp-Source: APiQypJIiFKtYelv/xA/eDtlm3DuLNDcuaVc4J3fQJgl+DNtCgHhU0eUD9ofChejz5+dMac+W8J5 X-Received: by 2002:a05:6402:1543:: with SMTP id p3mr19695778edx.333.1587478266761; Tue, 21 Apr 2020 07:11:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587478266; cv=none; d=google.com; s=arc-20160816; b=ZecHfSqzxc0xYijBMN30pcLk0AIzN+uj9RDYX7jMjnt4/avASzvrMrvZHIvePAe9Ik gr0QJ9H57bPW7y/0eWAHtP/n4BpMzGVJxOr2A53Si7MbBr5cgE7PENjoEDoQKz6EvsMJ Er4dAvd1MO9akBoWZGy7vEI8Rmnmwri7slt5hdTb0U6XihQ2PZmxpX2QWDA8Pk24dC67 IKvvTNJUJ7YbNgk8L5LtoID5RUg13KpMwYkJT6jJn6n5K0Ew+khb2yyBfvJFC32+ZTE8 S57muN7E4LTP+OB0kNPnAn2NNN1ilYrmmZkaUBREWmRaLyAzUuoLt8y5XEQ8Ri924wyR G2wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=38Z7bCrKGOqTsC0KSzv1nxq1EKpJrvY6ufXZM7Jy9PU=; b=AuqHge+EHIp7MDcukETmYc+AX/OiWNGkKSuHXA1FQV2+n3Mt2JYQxQlys140IhZJ6W UzRur3D7pX2pBurgGRYqCrWlYbaBbghzOR7RWZ6UkJEqhv8NXMzzMwkS1ULo0zm8frqK CEuJcp/7t2WOuANvXQGAr8GJll7IMXIbz0OFgsocL95f/u3lIklRHfOnA47da6xUT5lm UfryEzprtoLo5OKT2Cpq4rFq0u3eZuBrya1JgA6kNAVQm+CZkTi7tkA1nbK1XDDQDSDB qH8US7OQlVNq1ok4IVG6TIn5qd+fdcl2hQbFmNsEIHAMlqAm7ksv/5/I4L86owKeKr/c p8iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="yFw/bG6w"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b3si1485634edn.402.2020.04.21.07.10.42; Tue, 21 Apr 2020 07:11:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="yFw/bG6w"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728519AbgDUOJj (ORCPT + 99 others); Tue, 21 Apr 2020 10:09:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:33606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728316AbgDUOJi (ORCPT ); Tue, 21 Apr 2020 10:09:38 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC31C20679; Tue, 21 Apr 2020 14:09:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587478177; bh=47dRdhfCGfscyToO3yQIR/h3qAEu9MIShpFMyDMcDmI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yFw/bG6wzQTTx41T7fqFE/rQqJQh+ZXKvwN8atl/NcYeL9chbqyoSJAH8F38mH+gq F7I99+ZbrVRFK+sSpqtfFJ9fRG8x1ZP61XCwnFYL50Sk3k2u7Yfn6VShMA08vaTpDZ 190GqcI/SyUD/BjsR16rZ4j5fqpbKO51eqOzt3mk= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jQtah-005Cye-Tb; Tue, 21 Apr 2020 15:09:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Apr 2020 15:09:35 +0100 From: Marc Zyngier To: Valentin Schneider , Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Andrew Morton , Thomas Gleixner , Yury Norov , Paul Turner , Alexey Dobriyan , Josh Don , Pavan Kondeti , linux-kernel@vger.kernel.org, "Rafael J. Wysocki" Subject: Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq() In-Reply-To: References: <20200414150556.10920-1-qais.yousef@arm.com> <20200421121305.ziu3dfqwo7cw6ymu@e107158-lin.cambridge.arm.com> Message-ID: X-Sender: maz@kernel.org User-Agent: Roundcube Webmail/1.3.10 X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, qais.yousef@arm.com, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, akpm@linux-foundation.org, tglx@linutronix.de, yury.norov@gmail.com, pjt@google.com, adobriyan@gmail.com, joshdon@google.com, pkondeti@codeaurora.org, linux-kernel@vger.kernel.org, rjw@rjwysocki.net X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-04-21 14:18, Valentin Schneider wrote: > On 21/04/20 13:13, Qais Yousef wrote: [...] >> I CCed Marc who's the maintainer of this file who can clarify better >> if this >> really breaks anything. >> >> If any interrupt expects to be affined to a specific CPU then this >> must be >> described in DT/driver. I think the GIC controller is free to >> distribute them >> to any cpu otherwise if !force. Which is usually done by irq_balancer >> anyway >> in userspace, IIUC. >> >> I don't see how cpumask_any_and() break anything here too. I actually >> think it >> improves on things by better distribute the irqs on the system by >> default. That's a pretty bold statement. Unfortunately, it isn't universally true. Some workload will be very happy with interrupts spread all over the map, and some others will suffer from it because, well, it interrupts userspace. > As you say, if someone wants smarter IRQ affinity they can do > irq_balancer > and whatnot. The default kernel policy for now has been to shove > everything > on the lowest-numbered CPU, and I see no valid reason to change that. Exactly. I would like to keep the kernel policy as simple as possible for non-managed interrupts (managed interrupts are another kettle of fish entirely). Userpace is in control to place things "intelligently", so let's not try and make the kernel smarter than it strictly needs to be. Thanks, M. -- Jazz is not dead. It just smells funny...