Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1267858pxj; Wed, 19 May 2021 02:04:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyLWDZikIxvB+vpPozVsk5a28BQgmGiMOd+vW11xV6FY0+92MaFnzFBmXtLngWAGuC0Z4VP X-Received: by 2002:aa7:d607:: with SMTP id c7mr12904833edr.255.1621415043133; Wed, 19 May 2021 02:04:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621415043; cv=none; d=google.com; s=arc-20160816; b=U1t+OOfkw5xdm6ugNafmEyQK/4Whq6teaPC5iOVdraDC4R0Jt7wRvDf/YvNavvDqY2 4igEzJYLUzM014qXQ5LV8GIFpPcrOPlCJ3+qOg/6Vr5/i3RadW7f8swrZijkIvEebQ/F OYs23ZDggrhtMIhY9Mvr3J+dr9zZEOjRMYVide7QUZDKly5HzvTvjic5ONHXcoe/OgVR R7y0odpSEQV0JxgG2wfYZjtDfc2HpNIM8aIhNtsGfEI6d5g5iaQ9ZmoFaOgWoIT34iRa 64CP2r+iFu+HWo5RBr8iGSi7l3o5FNg81TfWI6RPL7UQIFZSjv43r+nJHIpt4IoklwAs r1VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=PzeDuFKqOdq6XOChkUVF1K14DQOzccWrFoItEVYjLtI=; b=VvjQ8wCT3a16htpohWGSxLRDDRiic4JB6UoT0Z2t13/vsyPeKhgFTp3HCZMwgvetfd 9WU4TUcWZM3oQV5ZfrYcbQfVypueyqhcZFOzsjbA0fHZ3lsG0slqly4x4UadqNcDwN4h qLTZ9pJldzWuVUR6fp9aTJVg4OSIq1w1t4JW/h6Oqm7sPqQ1qPwD+Fm8fikzYa0ynUJC xa4Kqx2Cn7CbUziXhncQ42N/HEQr3Aa4xr/dlqb9QDyBiWXTEyCLn+Bfa2FCJi4tYwqM PNfmy2sx78MKP3/AL6hAIkK+KJCeoebJHVZ86i2eJJWTMvme9SgFU1rQ3MDwfNdsCXu9 M2Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L61zr0Cb; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q15si13754906edw.475.2021.05.19.02.03.34; Wed, 19 May 2021 02:04:03 -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=@redhat.com header.s=mimecast20190719 header.b=L61zr0Cb; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344084AbhEQWqE (ORCPT + 99 others); Mon, 17 May 2021 18:46:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:21325 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344069AbhEQWqB (ORCPT ); Mon, 17 May 2021 18:46:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621291484; h=from:from:reply-to:subject:subject: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=PzeDuFKqOdq6XOChkUVF1K14DQOzccWrFoItEVYjLtI=; b=L61zr0Cbj4Y9P2kE99SUkfC+/y0NdNkYcIj6JnBKPhgTvNuWaZPBdMtBJAZh3lA5uHgTdJ xj10Qsut4VP4/2jGDeJZQF8oyYFLDuxJc60oNviAtgy4az5YdtjHvNF1oXDfvJVRE0q70F afwEpmafhNA+/gapO1loPirKNCSxNqE= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-8-BV0X2m8WNeKDZJK9UCB87g-1; Mon, 17 May 2021 18:44:42 -0400 X-MC-Unique: BV0X2m8WNeKDZJK9UCB87g-1 Received: by mail-lj1-f200.google.com with SMTP id a23-20020a05651c2117b02900e9751e7410so3757582ljq.6 for ; Mon, 17 May 2021 15:44:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PzeDuFKqOdq6XOChkUVF1K14DQOzccWrFoItEVYjLtI=; b=HCkqsB5pIrrUdXYgHGrJlk94X6mPtoZC7PvbvdXerazFrxWBsoIjgmQcUr5QMFFpat opq/jWHtPHG6bi8lQ2M6ur8W/9n6kbccUIh+AQGtpKpG2PrZYQHSTuw7gIINXHlkcuR0 EPhl+qF2Rn5vB+GF9ErVCahM3hoHCqMRxGEr8cMjAaURY09SoXuANwTTb0fC5zwmQmcR qO/P7RRSpDG0lJXp9K1+Kg77bpRqLj7l0/H9GrAY6WElqwIa4JP09D3qQqaUKJyV71++ /Hp82hP3/6gO1CIyMriXzT6PP3yocL8vyYJcWFZ5KEz7UF1FhBXI5RobPP4Lr4kDUHoT 7JGw== X-Gm-Message-State: AOAM530dNQZKhbFdVZFnOc+Ozd7qfgKxyD4Y8qaq25RpoFQF9ljlVrKM RCTE/rjwuEKgXXiqtE3V1iJHNevD/HyaCI0RKg0+OLy3yZhBHbnRb+VL1mS9CzITJefuQF8fB7u m+Gu1S7ghinmtbagusb03gfeoI9sdcuCijisTPQ4X X-Received: by 2002:a05:6512:3da1:: with SMTP id k33mr1581761lfv.114.1621291480842; Mon, 17 May 2021 15:44:40 -0700 (PDT) X-Received: by 2002:a05:6512:3da1:: with SMTP id k33mr1581740lfv.114.1621291480634; Mon, 17 May 2021 15:44:40 -0700 (PDT) MIME-Version: 1.0 References: <20210504092340.00006c61@intel.com> <87pmxpdr32.ffs@nanos.tec.linutronix.de> In-Reply-To: <87pmxpdr32.ffs@nanos.tec.linutronix.de> From: Nitesh Lal Date: Mon, 17 May 2021 18:44:29 -0400 Message-ID: Subject: Re: [PATCH tip:irq/core v1] genirq: remove auto-set of the mask when setting the hint To: Thomas Gleixner Cc: Jesse Brandeburg , Robin Murphy , Ingo Molnar , linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, jbrandeb@kernel.org, "frederic@kernel.org" , "juri.lelli@redhat.com" , Marcelo Tosatti , Alex Belits , "linux-api@vger.kernel.org" , "bhelgaas@google.com" , "linux-pci@vger.kernel.org" , "rostedt@goodmis.org" , "peterz@infradead.org" , "davem@davemloft.net" , "akpm@linux-foundation.org" , "sfr@canb.auug.org.au" , "stephen@networkplumber.org" , "rppt@linux.vnet.ibm.com" , "jinyuqi@huawei.com" , "zhangshaokun@hisilicon.com" , netdev@vger.kernel.org, chris.friesen@windriver.com, Marc Zyngier Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 17, 2021 at 4:48 PM Thomas Gleixner wrote: > > On Tue, May 04 2021 at 09:23, Jesse Brandeburg wrote: > > I'd add in addition that irqbalance daemon *stopped* paying attention > > to hints quite a while ago, so I'm not quite sure what purpose they > > serve. > > The hint was added so that userspace has a better understanding where it > should place the interrupt. So if irqbalanced ignores it anyway, then > what's the point of the hint? IOW, why is it still used drivers? > Took a quick look at the irqbalance repo and saw the following commit: dcc411e7bf remove affinity_hint infrastructure The commit message mentions that "PJ is redesiging how affinity hinting works in the kernel, the future model will just tell us to ignore an IRQ, and the kernel will handle placement for us. As such we can remove the affinity_hint recognition entirely". This does indicate that apparently, irqbalance moved away from the usage of affinity_hint. However, the next question is what was this future model? I don't know but I can surely look into it if that helps or maybe someone here already knows about it? > Now there is another aspect to that. What happens if irqbalanced does > not run at all and a driver relies on the side effect of the hint > setting the initial affinity. Bah... > Right, but if they only rely on this API so that the IRQs are spread across all the CPUs then that issue is already resolved and these other drivers should not regress because of changing this behavior. Isn't it? > While none of the drivers (except the perf muck) actually prevents > userspace from fiddling with the affinity (via IRQF_NOBALANCING) a > deeper inspection shows that they actually might rely on the current > behaviour if irqbalanced is disabled. Of course every driver has its own > convoluted way to do that and all of those functions are well > documented. What a mess. > > If the hint still serves a purpose then we can provide a variant which > solely applies the hint and does not fiddle with the actual affinity, > but if the hint is useless anyway then we have a way better option to > clean that up. > +1 -- Thanks Nitesh