Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp81184rwb; Fri, 12 Aug 2022 14:52:21 -0700 (PDT) X-Google-Smtp-Source: AA6agR6ZPEAXio5I1dFhgib0LUASaTnkswbfI4hgytyiMWwGW8nvfNWR9gVWybzSNGK+G7uCqhxx X-Received: by 2002:a63:5f09:0:b0:41c:da4f:e498 with SMTP id t9-20020a635f09000000b0041cda4fe498mr4756752pgb.276.1660341140944; Fri, 12 Aug 2022 14:52:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660341140; cv=none; d=google.com; s=arc-20160816; b=kezKA/4kahFOU+usMDibsTV+QVQwxkwkoAKDUDZgUOuIJM0hh5M5nan782bvVbhSfl WRQOINV11M+HekVQoKxQruw9mFJZHhZoKrznM18920S2tud03oOVNKsrqsL77oYM09Hg x6yjodsN/GjVfz1xsRBbqQbIPoRoHz/RhLK+zk3ZN2A/0jav2aqCSwNnWdC3Np3CAPzg os05n3Ickn4MXEzDA29HrmIBwO62uz+fM0VCP4wjf5e2Ah9VLYJa0ZavAI8RQhGTkgKs PRszzAj7pg6qPaFyyCFJhG9h2xhE16uLx/HwEE6SHnNgCzvfbAwJduHgQjEo+16LTGKL Ykgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=HsCUQ8j36I4b68/toXmGXuF2hsPiyYP9smjWccI2rQk=; b=gUyKFIvdWrBmC8RQe7IJoyo547wEBqVVT3uqWN0U4irbJo05d+k072fu3mOu6J3xVG jGMAfQyHHEZfAaLJAz8SReIDLov5GQTE1p+Z/f0L9jU1DUBhNXX1vKjQDmAGggnK0zRt TuSlZpT3ZzB+1nPARgcnTtBGtHVE1Lxyq7GqytFjBuOBChujYitV+kvlJ+9qnlQXCjZG LLW32aWQtTV+YalGOzeJlu/Gyix82xmHsAKHlQcOrWwJVdMRSqpPVW5DAsX51GP610DN vr/ADtlPZxEFj4/MO/CSJro1yW8QhqWiNPVzq9qN9HNOtVUVh5fPee5uD74fzT6Li2ag 7NVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=T8edxcRX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id iw18-20020a170903045200b0016d0bf9a5f5si3118480plb.110.2022.08.12.14.52.07; Fri, 12 Aug 2022 14:52:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=T8edxcRX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S236034AbiHLVnO (ORCPT + 99 others); Fri, 12 Aug 2022 17:43:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233784AbiHLVnM (ORCPT ); Fri, 12 Aug 2022 17:43:12 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 121DEB07E2 for ; Fri, 12 Aug 2022 14:43:10 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id 17so1833679pli.0 for ; Fri, 12 Aug 2022 14:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc; bh=HsCUQ8j36I4b68/toXmGXuF2hsPiyYP9smjWccI2rQk=; b=T8edxcRXD18BsL1RTMjGrj5n5dQsaZ4ojGAmMwVXKsYJdht7fJ7wztz/lJ1kLjnRrU 6Q7c32Y6LN1DE3ooBXiX1OUl6mf/pVEtG+KgbRHbR6NKEp0cSOrtaM+jq500rZ+KzukA mc/wTkGgq4u9MKsQT0i919rJABVE6il55R8QLPNON59KLiyPH0abZHeRnsixJqjlZz74 P1pnhPNaFVgWLAU+ZB+dW7vmVM7yHyVBv3Z4Ldo9oUzYBcC34Z8ZXJTo29AtuInBURZU nEx3PPBKtG0g1ceLACYgAXiP6itMQ9oIL1UEEjnecWNcY+pVJiNV/pMKYRyNMh++rqv+ CmOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc; bh=HsCUQ8j36I4b68/toXmGXuF2hsPiyYP9smjWccI2rQk=; b=56dTKwI4rBtqpmwmwioXb9W9QxyXQALAtiy8vCopIJwNYHKCVi6syI83Z18/Q8sgS6 8mPWpUgia8BSnCBqoK1/aJfw1CRtMD/3qoswikKuHsSezo3LOAWsybUFWioTCWLbMLyj CY67hyOk39LHICliEk6hNMxFVwbi3VAmOxPay4p/jOJDBCSESV0hNDfbraLfdC0CBGqc QtnhvzLmPps2/+eXDw8VZ6x5YXB08SzHjRIHRjhBxtqNrZZNcDA7WXcuHCA6MW4V4xwv BJspG1J0757vcHNU0NnwbotenowMNBsY4fOtRw1tlSk7F7lxqBBSGuANsS7wPfi1jWol G5hQ== X-Gm-Message-State: ACgBeo2H4O5ytQ4R4D9fYjhDfm5TzEFo3vGfl2pF1sBL11k1T1+vDCI4 jIPJUBk7X7FWyWx78fLzQDknFxn6OI8= X-Received: by 2002:a17:90a:d70f:b0:1f3:290b:c8f6 with SMTP id y15-20020a17090ad70f00b001f3290bc8f6mr15857826pju.190.1660340589426; Fri, 12 Aug 2022 14:43:09 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:aae]) by smtp.gmail.com with ESMTPSA id g23-20020a63e617000000b0041cd2417c66sm1762561pgh.18.2022.08.12.14.43.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 14:43:08 -0700 (PDT) Sender: Tejun Heo Date: Fri, 12 Aug 2022 11:43:07 -1000 From: Tejun Heo To: Felix Kuehling Cc: Philip Yang , Lai Jiangshan , "linux-kernel@vger.kernel.org" , "amd-gfx@lists.freedesktop.org" , Maling list - DRI developers , Dave Airlie Subject: Re: Selecting CPUs for queuing work on Message-ID: References: <82233e68-106f-39e9-b20d-7794eb7a8933@amd.com> <5256fc4b-437b-f7fb-55b6-abab091e0182@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5256fc4b-437b-f7fb-55b6-abab091e0182@amd.com> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Fri, Aug 12, 2022 at 04:54:04PM -0400, Felix Kuehling wrote: > In principle, I think IRQ routing to CPUs can change dynamically with > irqbalance. I wonder whether this is something which should be exposed to userland rather than trying to do dynamically in the kernel and let irqbalance or whatever deal with it. People use irq affinity to steer these handlings to specfic CPUs and the usual expectation is that the bottom half handling is gonna take place on the same cpu usually through softirq. It's kinda awkard to have this secondary assignment happening implicitly. > What we need is kind of the opposite of WQ_UNBOUND. As I understand it, > WQ_UNBOUND can schedule anywhere to maximize concurrency. What we need is to > schedule to very specific, predictable CPUs. We only have one work item per > GPU that processes all the interrupts in order, so we don't need the > concurrency of WQ_UNBOUND. Each WQ_UNBOUND workqueue has a cpumask associated with it and the cpumask can be changed dynamically, so it can be used for sth like this, but I'm not yet convinced that's the right thing to do. Thanks. -- tejun