From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 8C2CC272E5A for ; Wed, 19 Nov 2025 22:11:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763590265; cv=none; b=liVuDhUFKqcDtbdflq4sjwrOn74uKlLjMCDZ4hvN63SM70g3EUTd37yYWQlk60uYZDkU5wNdEg36vw4DB21ml8c8y07jjbNYP32jNAY62gLka1RBrZepmZALzEt6xyopXTH6LXwaXEej32Nk/IGwHPW98IiUojRRxHSf73sxJiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763590265; c=relaxed/simple; bh=wPmG0fCHFa8+zw72JC1/PuPoaXBnCCa/x0KNYzSxT20=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ulDyE+69165ypqToG/ReqaNjK1Qtsut+JWRj2ZOSVFRbQoV60qJegpCuvUxKUIs8A6w1zWOokfbCoidAfyTcSCrzxnQsohB47ZDSYQ4ThtH8OP508hi6wVUCAImwH072WtYzoTNc4qdZSOZEPbwFYx2g8l2TV/O/vAvo9ssrpmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Zc9ci9zK; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=ZWvWYi3H; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Zc9ci9zK"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ZWvWYi3H" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763590259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jH1q19nqZ/Y6LOG3PWKFzEkpT0bgZBlnqryNjgzVAsM=; b=Zc9ci9zKmRM9ntJKhofaWM1s9Ppj66ESUpfz98ksnucK9GAZayxASRgPB3JvI78gJZ4uNm o4qlSXDLNgDUPtvAwlQHnbMnpe/pdPcogCuSSVZAtny2H8kRMg/i5LIDpW2cFjrff6ueYZ +l9DnLaGX2Mzz8DYrPRwc5GMqT88VcytkTBGF3KQZYR9WYgG6jgy3NRX6zWse8qwMvB2bh CdCXx6RK6LV3TdP6Xga1nqAzsQm4QaWoiyTMHBEZFMthpkubwwsg3mbhbQuu9nIL0XHjR9 O5klQItCpij0PT+YKM/PGAX3x9xelQTK7HRlPpMwN/raeQ3t2MXYufqD3ZKXzw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763590259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jH1q19nqZ/Y6LOG3PWKFzEkpT0bgZBlnqryNjgzVAsM=; b=ZWvWYi3HPI8e+HTsEze+XO1wkztcsjbrT3mV88j7A49u9wtxBTPbaM0FKtyWXE1CYHG1jh O7amLThUSK+sw0DQ== To: Frederic Weisbecker Cc: Gabriele Monaco , linux-kernel@vger.kernel.org, Anna-Maria Behnsen , Waiman Long , "John B. Wyatt IV" , "John B. Wyatt IV" Subject: Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration In-Reply-To: References: <20251113083324.33490-1-gmonaco@redhat.com> <20251113083324.33490-8-gmonaco@redhat.com> <87pl9eklvc.ffs@tglx> <87jyzllwhd.ffs@tglx> <87fra9lnsw.ffs@tglx> Date: Wed, 19 Nov 2025 23:10:58 +0100 Message-ID: <87cy5dlll9.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 19 2025 at 23:02, Frederic Weisbecker wrote: > Le Wed, Nov 19, 2025 at 10:23:11PM +0100, Thomas Gleixner a =C3=A9crit : >> If you want to be a bit smarter, then you can just use a global mutex, >> which is taken inside the set/clear_available() functions which >> serializes the related functionality and bulk schedule/flush the unisol >> (make available) first and then proceed to the isol (make unavailable). >>=20 >> Then nothing has to change vs. the set/clear operations and everything >> just works. >>=20 >> That mutex does not do any harm in the CPU hotplug case and the >> serialization vs. the workers is not going to be the end of the world. >>=20 >> I'm willing to bet that no real-world use-case will ever notice the >> existance of this mutex. The microbenchmark which shows off the "I'm so >> smart" metric is completely irrelevant especially when the result is >> fragile, incomprehensible and therefore unmaintainable. >>=20 >> Keep it correct and simple is still the most important engineering >> principle. Premature optimization is a guaranteed path to failure. >>=20 >> If there is a compelling use case which justifies the resulting >> complexity, then it can be built on top. I'm not holding my breath. See >> above... > > Perhaps the only thing that worries me is if an isolated partition > is inverted. Say 0-3 is non isolated and 4-7 is isolated. And then > cpuset is overwritten so that the reverse is applied: 0-3 is isolated > and 4-7 is not isolated. If all isol works reach before unisol works, > then tmigr_clear_cpu_available() -> cpumask_any(tmigr_available_mask) > won't find any CPU left on the last call. schedule the newly available (now unisolated) ones first and flush that work. After that you can safely mark the others unavailable, no? Thanks tglx