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 7A0EFC001E0 for ; Tue, 25 Jul 2023 11:22:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234461AbjGYLWz (ORCPT ); Tue, 25 Jul 2023 07:22:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234455AbjGYLWy (ORCPT ); Tue, 25 Jul 2023 07:22:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 021021BEC; Tue, 25 Jul 2023 04:22:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 85AEC6168E; Tue, 25 Jul 2023 11:22:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 605A4C433C9; Tue, 25 Jul 2023 11:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690284164; bh=3PZwNojel/fB0iAxHMvVvEfU8vg+2OWEs6gC1RrNPhs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ug3Bp0moAtl2iOU0LqyL6tock6eXDiL1XykMzJHwS26YFDBZTp2nVVg5DegFC95W1 wDJLMEHXkEgb5ZX1TQ495uXTpRNdYAXZ0H74hGRGrgpvceN4JFUqF6/WhthIgQOoXb XvH/x8Td6KU4anPDoEwiqQRHT7TSms9g3xsZZT/xKIcjy12Z7QZkhJPm6IYHGnAxUf /7VrDt7orGvGidvZWlI4CS9xmnPnE8482azX1QUUGJEU3qAo3Aq5g2wHoRF8lZwyFA aKaa6T74oelllGzL5yE1ufrOMNi/c0qdUFY7RpOaL4AoiPSzhULoGduWnosuWAb/0L PhJHNPXC3RiRg== Date: Tue, 25 Jul 2023 13:22:42 +0200 From: Frederic Weisbecker To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, x86@kernel.org, rcu@vger.kernel.org, linux-kselftest@vger.kernel.org, Nicolas Saenz Julienne , Steven Rostedt , Masami Hiramatsu , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Wanpeng Li , Vitaly Kuznetsov , Andy Lutomirski , Peter Zijlstra , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Josh Poimboeuf , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Nadav Amit , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Juri Lelli , Daniel Bristot de Oliveira , Marcelo Tosatti , Yair Podemsky Subject: Re: [RFC PATCH v2 15/20] context-tracking: Introduce work deferral infrastructure Message-ID: References: <20230720163056.2564824-1-vschneid@redhat.com> <20230720163056.2564824-16-vschneid@redhat.com> 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-trace-kernel@vger.kernel.org On Tue, Jul 25, 2023 at 11:10:31AM +0100, Valentin Schneider wrote: > I have reasons! I just swept them under the rug and didn't mention them :D > Also looking at the config dependencies again I got it wrong, but > nevertheless that means I get to ramble about it. > > With NO_HZ_IDLE, we get CONTEXT_TRACKING_IDLE, so we get these > transitions: > > ct_idle_enter() > ct_kernel_exit() > ct_state_inc_clear_work() > > ct_idle_exit() > ct_kernel_enter() > ct_work_flush() > > Now, if we just make CONTEXT_TRACKING_WORK depend on CONTEXT_TRACKING_IDLE > rather than CONTEXT_TRACKING_USER, we get to leverage the IPI deferral for > NO_HZ_IDLE kernels - in other words, we get to keep idle CPUs idle longer. > > It's a completely different argument than reducing interference for > NOHZ_FULL userspace applications and I should have at the very least > mentioned it in the cover letter, but it's the exact same backing > mechanism. > > Looking at it again, I'll probably make the CONTEXT_IDLE thing a separate > patch with a proper changelog. Ok should that be a seperate Kconfig? This indeed can bring power improvement but at the cost of more overhead from the sender. A balance to be measured...