Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp3273176rdb; Wed, 13 Sep 2023 07:23:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFEk/rg77DyJWIuhesVUpxkUwKXOjg1y48YmqLXoRsdF9eiaIB3Ofhmp5+zQhN1ucMq5Nif X-Received: by 2002:a54:470e:0:b0:3a4:225f:a15b with SMTP id k14-20020a54470e000000b003a4225fa15bmr2968633oik.31.1694614985570; Wed, 13 Sep 2023 07:23:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694614985; cv=none; d=google.com; s=arc-20160816; b=VTvI+q8kjGk1ckF/JO0KYVMPa84LugksKWxHQzwqNVqAiKauGGQ4xwmi/W066nTjln xyOdar22+VWtOcsXgcp4PVPsveBAxmWtKIutwMHpZQmHcN7yzd4Iipps6L11/NSS/Fmv 5LRvgJwMX60D6Tsg0CeYaRzhALwEeV9zYxCdg1ia11NhiZQ3ojutRjKtbhDqI0KMGCqH bTsUs6/3G63wZISpuXn5LVV9mG2JJytcRouTWL3jASnnvmQFuXNn+shun4I7C/01AKxK Yx4h4jhdM0rAlecBUl0I/E1sbrDND0GPIw816rdr7RCapIEQiDApMrLciBWyQXkGsjpr gVFw== 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:mime-version :dkim-signature; bh=Vy7JcxjX2sI8J+tYRSHZ5xGLUxgOH8JQq+vqCf2qAy4=; fh=D/SJMcqOupiaBXjJy7uZQ/XUJBvTG6zs7Q3pCriIRnA=; b=EGfG10WFergpAlaSxf+pi9N0T7h2aT6ojK/oem+bslkuvZJ97OU/cZ7o43YRR/vSBl Sa/DmgX0mWK5bfIjCOdFtuorJfpi94FebzGaOoMNK/zIWsA7XvS4Wl5PyFa6G39+Nht8 qgzAxSq4pJ3qmu/adVv6U4ucsrrN9kkcVDQnGf+5DD4qtIZDXykeDkjfTRWlcOAY6d33 4QZd+uQCln8ErOEVxMOTKs0+wBCG7m9OnvkzsszFXDLF/UM//VsF3g8aa7MZpp0TGMmr WtvThN0X77TgknQHXBp9YknI2PedNeJkol8kCDq/YpATX5ed2AHTD5wcZCFAi3JEoClz y5DA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=B5vkjBE7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id r5-20020a632b05000000b00577549e67b9si7332390pgr.589.2023.09.13.07.23.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Sep 2023 07:23:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=B5vkjBE7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 18065825A0C2; Wed, 13 Sep 2023 05:49:28 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232971AbjIMMtY (ORCPT + 99 others); Wed, 13 Sep 2023 08:49:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234730AbjIMMtW (ORCPT ); Wed, 13 Sep 2023 08:49:22 -0400 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 025F719B6 for ; Wed, 13 Sep 2023 05:49:19 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id ca18e2360f4ac-77a62a84855so249493139f.1 for ; Wed, 13 Sep 2023 05:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694609358; x=1695214158; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Vy7JcxjX2sI8J+tYRSHZ5xGLUxgOH8JQq+vqCf2qAy4=; b=B5vkjBE7s2YR6tOPvaE3ybgBDPwNvwLdUSEAViLJLq+eSpclJNAu7NWB5dHVHm5xE6 DRMKT9MkFciRNlkafqNOdANn1/cmC2gn7rLXk4zKmFje4fW70FDlbUusxnT4ZTTxL1MK t/qSzFBLhURwtZZj/HAif8yRkx9RVz/HWgB56KTfaAVN9sI1F9pDO7U7K0+Au+E4WuWK 6weWy8kgvzNfMiYB4CZgCh+Za2Y4GZxk+ThQBEhMLpn04JVPByoMfN6LNoelcGnJS/vx PpZBNZtrFiMGGt3lJ6CIqtCdOj7TJKTigZAq8uS/cNPYp8UBvv0l3lhUkqoMpUj7QHYC HHWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694609358; x=1695214158; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Vy7JcxjX2sI8J+tYRSHZ5xGLUxgOH8JQq+vqCf2qAy4=; b=fhuwaO1dOVKUUU1kLRlyToQ+TCGu6ibagskfHu/tng7DxaZquTXwrOgjZnMWVBcDnX BHfpOXQE8TIp3/qR725MrxMFqb6D8TSo6gOb8kAxaw+aPsEB/FH3RTq9lgR4Dj9cwQPb NuSl4h5DaO/DEfyiMfpL3lX1sL0ZQzcJ9X9ok/4I9bgci07zW6wKZYXFWMZ86hD3iYur nJn6wEsGpoZgcm+qiUaX6jqyc6dw//qV1mHGZ7gKSI/FLGbIFPO/JOBfd0xt9U1c7j1T +gY6iwK+aYMY8ZwEpr0925Lo2uNAx8Y2aqe7rqNwjoXoWO1rid1aHQBRUwoqyp7Hgrs1 lkvQ== X-Gm-Message-State: AOJu0YxeHabqi2T918nQbdUf0KqjRWlis0YjiSLJXretD3bXlP/PtWGv 3Uxm7y2l9mHtuVSTvrLBGRuqtq1XZ5dJgTM9IX7Cyg== X-Received: by 2002:a6b:7a4a:0:b0:780:d76c:b640 with SMTP id k10-20020a6b7a4a000000b00780d76cb640mr2811549iop.9.1694609358299; Wed, 13 Sep 2023 05:49:18 -0700 (PDT) MIME-Version: 1.0 From: Suleiman Souhlal Date: Wed, 13 Sep 2023 21:49:07 +0900 Message-ID: Subject: NOHZ interaction between IPI-less kick_ilb() and nohz_csd_func(). To: Peter Zijlstra Cc: Ingo Molnar , Juri Lelli , Linux Kernel , Steven Rostedt , Joel Fernandes , Vineeth Pillai , Youssef Esmat Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 13 Sep 2023 05:49:28 -0700 (PDT) X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Hello, I noticed that on x86 machines that have MWAIT, with NOHZ, when the kernel decides to kick the idle load balance on another CPU in kick_ilb(), there's an optimization that makes it avoid using an IPI and instead exploit the fact that the remote CPU is MWAITing on the thread_info flags, by just setting TIF_NEED_RESCHED, in call_function_single_prep_ipi(). However, on the remote CPU, in nohz_csd_func(), we end up not raising the sched softirq due to NEED_RESCHED being set, so the ILB doesn't end up getting done. Is this intended? Thanks, -- Suleiman