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 X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E99CC433ED for ; Fri, 21 May 2021 00:04:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 28B1C6138C for ; Fri, 21 May 2021 00:04:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234733AbhEUAFT (ORCPT ); Thu, 20 May 2021 20:05:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:37120 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231628AbhEUAFQ (ORCPT ); Thu, 20 May 2021 20:05:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621555433; 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=yY5C4rKyGeidFpZPaRAHZm77aYdXwBLOJbXSDp6aeQo=; b=IrF0hc4kWrKQ0HfMBePMYtrv1LzTPUzpMXaTAaM9UgunaJOVidXYLwFdHiXsIbo2cnV5Zc 4A7N6jrR0lN3sBpg66gThLjuicMSzrwCLIrMp2SMChKvKcH4CFMFi/nB0RXPNpoC6CB5cb 4W/UKf+3RFix6/cU2dyGIFOASk9EFgI= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-528-2n40PGZiP16_vmcwtu3qlw-1; Thu, 20 May 2021 20:03:52 -0400 X-MC-Unique: 2n40PGZiP16_vmcwtu3qlw-1 Received: by mail-lf1-f69.google.com with SMTP id z1-20020a195e410000b0290229c07c3305so4316401lfi.11 for ; Thu, 20 May 2021 17:03:51 -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=yY5C4rKyGeidFpZPaRAHZm77aYdXwBLOJbXSDp6aeQo=; b=I1xcwFlS8vqsqmJ7gtFdd+4VIBduQ1meS3bfTjRO/uci4+I+cmhdHucDVDjSzR0k+e ugydsljtXXEzrKo4xruQHqeyL6bzHcBAla24jfxNo487WQjOdIkOJedZZRVkUfoND4Fv mU1cqvtev4vfEMkRhwNV5VJQi+BH4sl9zizB9cQpfzy9kVeSp1kkq1+d5hndtCgtzJy2 oV/tePqJz0Ap481jKls4cslYvcikSguDfgNnyjstg3Z8Q7cKrMJ7AU8wtl8STuT1XCb/ nA4Nyg1vF1k4/dr4utpdhw4BNQ1mP5Bp+KjX5lelL6C4dnoyYfkGbLIqfXLZvByNTtQN VC4w== X-Gm-Message-State: AOAM531w1qYgxdmNhVcTWyMtmhw8XHN9sJI3Gu0gouGX3mXOwk0I5wHV DZxKlxyfD7LZ90veuMAvaQaHo6C9hu/+Mfp5PTelKhNtCeGZRI4UnaqCIMnyzyStNzc/M8bwFi0 3ssH1owcNaTeCVHtt9AyceJYNoYsRi0MRVoUlcPQv X-Received: by 2002:a2e:1405:: with SMTP id u5mr4619206ljd.137.1621555430595; Thu, 20 May 2021 17:03:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPZc4H2Y4hAkVPTqEKOh1WdHXnKldKsyeMgCwEjITdNxHORoiwVToMhx6cyuK2hIWrTSLfeJEl7lCMqoeGy/c= X-Received: by 2002:a2e:1405:: with SMTP id u5mr4619179ljd.137.1621555430294; Thu, 20 May 2021 17:03:50 -0700 (PDT) MIME-Version: 1.0 References: <20210504092340.00006c61@intel.com> <87pmxpdr32.ffs@nanos.tec.linutronix.de> <87im3gewlu.ffs@nanos.tec.linutronix.de> In-Reply-To: From: Nitesh Lal Date: Thu, 20 May 2021 20:03:38 -0400 Message-ID: Subject: Re: [PATCH tip:irq/core v1] genirq: remove auto-set of the mask when setting the hint To: Thomas Gleixner , Jesse Brandeburg , Robin Murphy , Marcelo Tosatti Cc: Ingo Molnar , linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, jbrandeb@kernel.org, "frederic@kernel.org" , "juri.lelli@redhat.com" , 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 , Neil Horman , pjwaskiewicz@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 20, 2021 at 5:57 PM Nitesh Lal wrote: > > On Mon, May 17, 2021 at 8:23 PM Nitesh Lal wrote: > > > > On Mon, May 17, 2021 at 8:04 PM Thomas Gleixner wrote: > > > > > > On Mon, May 17 2021 at 18:44, Nitesh Lal wrote: > > > > On Mon, May 17, 2021 at 4:48 PM Thomas Gleixner wrote: > > > >> 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". > > > > > > No idea who PJ is. I really love useful commit messages. Maybe Neil can > > > shed some light on that. > > > > > > > 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 might have missed something in the last 5 years, but that's the first > > > time I hear about someone trying to cleanup that thing. > > > > > > > I don't know but I can surely look into it if that helps or maybe someone > > > > here already knows about it? > > > > > > I CC'ed Neil :) > > > > Thanks, I have added PJ Waskiewicz as well who I think was referred in > > that commit message as PJ. > > > > > > > > >> 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? > > > > > > Is that true for all architectures? > > > > Unfortunately, I don't know and that's probably why we have to be careful. > > I think here to ensure that we are not breaking any of the drivers we have > to first analyze all the existing drivers and understand how they are using > this API. > AFAIK there are three possible scenarios: > > - A driver use this API to spread the IRQs > + For this case we should be safe considering the spreading is naturally > done from the IRQ subsystem itself. Forgot to mention another thing in the above case is to determine whether it is true for all architectures or not as Thomas mentioned. > > - A driver use this API to actually set the hint > + These drivers should have no functional impact because of this revert > > - Driver use this API to force a certain affinity mask > + In this case we have to replace the API with the irq_force_affinity() > > I can start looking into the individual drivers, however, testing them will > be a challenge. > > Any thoughts? > > -- > Thanks > Nitesh -- Thanks Nitesh