From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B3E919C56C; Wed, 20 Nov 2024 10:54:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732100080; cv=none; b=TOHMF9oMcxIhIi7cVwUQ3xhZEqff+uvCAuA7OdLXnyZt/rDGB51S6NoFNDR9z2w4Gd0o2T8fINL0M41blsxhKihZC1vZ/We8w4F47KctN1qKHPNL+tkYvJcUUQYkDt8CXwBR5iKiSXigcb/lSyV+Anqi9reoTT5AqT3odlJse/0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732100080; c=relaxed/simple; bh=v56PH/TC6VfhJinSkV1dT70LzT5v+DrJrRasoRvKhFI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PVThZ6bq7YTY2BZvws/Er7PoUtNQt2VZVza7r8OHnAsaJxTykK721ELvfUNCiOJ+4+jNzBkKTFv8gmr8jxgv7Szjq/vwOc/MPX5CYqBzY6DvRj/H3ximyySznzJzcgf/YdWTMtZeLyvoJQWTZSi/WGOmZmiR9oCQPkHm+vgSqeo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oerig4Qz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oerig4Qz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 544F2C4CECD; Wed, 20 Nov 2024 10:54:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732100078; bh=v56PH/TC6VfhJinSkV1dT70LzT5v+DrJrRasoRvKhFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oerig4QzLHxMLkwFcONbh+QH7JccDk0DYE3OO/JNvQbbuExvz1IHXFtkNKc6ws900 Ph+vlJcQywEm83n2EWh8eOD3E6AZfrjvVpMWMXWX3fTt+R3wkNOnwGEEtf5zQCC2uo zm2de2K9vuAY5MO1/HoqnapioBJ0nJglbW9z3CJkqGC66wmic0Hh3Y8wS9bq3PAygE DQRp/srrPst1RiqG1ma/fqzGFR4rh5hRjKE6OJ7Hk2bXvOPwq0Ufil5r28O7veX/F6 Ad1KjhFA/txIArs9lwbKNUhi2TBYUTNnd4c9ugCn654jg7d9lyoYTrVJbr+9dD32Ud iibD+W02/qyJg== Date: Wed, 20 Nov 2024 11:54:36 +0100 From: Frederic Weisbecker To: Valentin Schneider Cc: linux-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 , Marcelo Tosatti , Yair Podemsky , Daniel Wagner , Petr Tesarik Subject: Re: [RFC PATCH v3 11/15] context-tracking: Introduce work deferral infrastructure Message-ID: References: <20241119153502.41361-1-vschneid@redhat.com> <20241119153502.41361-12-vschneid@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241119153502.41361-12-vschneid@redhat.com> Le Tue, Nov 19, 2024 at 04:34:58PM +0100, Valentin Schneider a écrit : > +bool ct_set_cpu_work(unsigned int cpu, unsigned int work) > +{ > + struct context_tracking *ct = per_cpu_ptr(&context_tracking, cpu); > + unsigned int old; > + bool ret = false; > + > + preempt_disable(); > + > + old = atomic_read(&ct->state); > + /* > + * Try setting the work until either > + * - the target CPU has entered kernelspace > + * - the work has been set > + */ > + do { > + ret = atomic_try_cmpxchg(&ct->state, &old, old | (work << CT_WORK_START)); > + } while (!ret && ((old & CT_STATE_MASK) != CT_STATE_KERNEL)); > + > + preempt_enable(); > + return ret; Does it ignore the IPI even if: (ret && (old & CT_STATE_MASK) == CT_STATE_KERNEL)) ? And what about CT_STATE_IDLE? Is the work ignored in those two cases? But would it be cleaner to never set the work if the target is elsewhere than CT_STATE_USER. So you don't need to clear the work on kernel exit but rather on kernel entry. That is: bool ct_set_cpu_work(unsigned int cpu, unsigned int work) { struct context_tracking *ct = per_cpu_ptr(&context_tracking, cpu); unsigned int old; bool ret = false; preempt_disable(); old = atomic_read(&ct->state); /* Start with our best wishes */ old &= ~CT_STATE_MASK; old |= CT_STATE_USER /* * Try setting the work until either * - the target CPU has exited userspace * - the work has been set */ do { ret = atomic_try_cmpxchg(&ct->state, &old, old | (work << CT_WORK_START)); } while (!ret && ((old & CT_STATE_MASK) == CT_STATE_USER)); preempt_enable(); return ret; } Thanks.