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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B6A0C77B7D for ; Wed, 10 May 2023 18:16:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231486AbjEJSQL (ORCPT ); Wed, 10 May 2023 14:16:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230440AbjEJSQJ (ORCPT ); Wed, 10 May 2023 14:16:09 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1562B61B0; Wed, 10 May 2023 11:16:03 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1aad5245632so54648195ad.3; Wed, 10 May 2023 11:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683742562; x=1686334562; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=MV9KKbnlL+o+b9x6xmrTpuZGcH+89cbdDhrFO47jPDI=; b=o5Y7xv20o5mb5unhzSkkqEMFLfZemZ3Fq7tIeDgj5NY1msy0Go/2xY/wrMzxSfT9D9 JwJMcse7ELe/2fUUuGgymqY0hXejB61olNuRHmUKr0Z8boiMUjl7njBt3h9xf/bNKwFd xVkjozoLCJQOL0/KCaHABwNZ0vbBae2mjSS+/jhRJl3/V91GXz7iWNNn4AVYNHoZSaYZ dmQvMPiRSQbmR9YgMom1IYy94DESmAzhyBARwsmm9FsMMHhdiJyPZwdij2iXvsuYkf93 miMGoKNSWCwprwfIgGEMuVLBCAWWkFDY5uJmxg4nDETy0lz5FHKo1Okb+ouDQemKHr15 o9Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683742562; x=1686334562; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MV9KKbnlL+o+b9x6xmrTpuZGcH+89cbdDhrFO47jPDI=; b=kzFRYuA0zfGGYB8TmhLvGuge5JkqplhH/PW8feAIumZXCORS1I/AQkRJwFCM3X2jzJ rl45HrjyXUQxNcMeyaZNJWwcKKirub4uSo8hVaMUjTworBVK2s0P1qDRrufEuKW/Qg4J U78vYdRYGn+Ntc2rSFcircIUAsPVYBLI2S2FP9WQotC0sdg0qSxh9DJcjtEJoA6ypLrn AbYbSB9eBRS4zX9pMjsCipf/nXROSuxtHTyRsPquj4RaconI2Y3H1ardRFUqHSVRH8d1 RPUqQPz1lNxLNUEN+iPVP1bemrc/7l8Jo9fKMuvo4BvNTS/NiepDBiWAHewnW+5fK2Qt 5ivQ== X-Gm-Message-State: AC+VfDxU4lXZEhmZ0yRzvjD+iBh78RzOgxOvlbDDA6tIZXldqq8GtH+A URUe24yybYPBTxGyuYEE5CY= X-Google-Smtp-Source: ACHHUZ5zdzxE/nxzHwipE7aLMexdW6UuNkId05cX7KuDNO37PTIHoYGXQ2ZzwwAuGUkqY/Bm0hpOJg== X-Received: by 2002:a17:902:eb4b:b0:1a6:7632:2b20 with SMTP id i11-20020a170902eb4b00b001a676322b20mr19942490pli.40.1683742562313; Wed, 10 May 2023 11:16:02 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id j12-20020a170902690c00b001a04d27ee92sm4082703plk.241.2023.05.10.11.16.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 May 2023 11:16:01 -0700 (PDT) Sender: Tejun Heo Date: Wed, 10 May 2023 08:16:00 -1000 From: Tejun Heo To: Brian Norris Cc: jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, kernel-team@meta.com, Amitkumar Karwar , Ganapathi Bhat , Sharvari Harisangam , Xinming Hu , Kalle Valo , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 02/13] wifi: mwifiex: Use default @max_active for workqueues Message-ID: References: <20230509015032.3768622-1-tj@kernel.org> <20230509015032.3768622-3-tj@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hello, On Wed, May 10, 2023 at 11:09:55AM -0700, Brian Norris wrote: > I'll admit, the workqueue documentation sounds a bit like "max_active == > 1 + WQ_UNBOUND" is what we want ("one work item [...] active at any > given time"), but that's more of my misunderstanding than anything -- > each work item can only be active in a single context at any given time, > so that note is talking about distinct (i.e., more than 1) work items. Yeah, a future patch is gonna change the semantics a bit and I'll update the doc to be clearer. > While I'm here: we're still debugging what's affecting WiFi performance > on some of our WiFi systems, but it's possible I'll be turning some of > these into struct kthread_worker instead. We can cross that bridge > (including potential conflicts) if/when we come to it though. Can you elaborate the performance problem you're seeing? I'm working on a major update for workqueue to improve its locality behavior, so if you're experiencing issues on CPUs w/ multiple L3 caches, it'd be a good test case. Thanks. -- tejun