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 197C21FA84A for ; Tue, 17 Dec 2024 23:30:12 +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=1734478215; cv=none; b=P0ANQ1k6aiBe7/ab49YiLAisYPw+SdtJNlAHBhqSVLD2MCtA6FgmtHMdsJELSPJopLlI7fLizyVGCCMSAFyJrg4OhkOnejyHm8oe2lU3kbq1jOKjIdRnugUg9F1DIAK0fLtF/q8Y8j+lR40lMXNHOa5NqRcrH+wsg0npeFdz4k0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734478215; c=relaxed/simple; bh=Kk1qPS68BjZFxzp4KVx3BrRPW1ccfi2FCR7sH301VBA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=KyRHWRK2d7BUxZGyffxSNzmw86c8ifEWmkZc9a3jl9V6gzSrSSObnofe6DieQAXnV3GCYUYKzaE4lxnG8rGxLHc5fz/NPxBRu3ZXR1RCpC3bbhS4yqxOFVSCyhzMzBKvyZ2yw8ZYYzGkL05R3afctX3EuLT8GzDN5xlCcjSz0Oc= 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=sqLtqTGg; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=H4+2Xpyd; 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="sqLtqTGg"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="H4+2Xpyd" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1734478210; 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: in-reply-to:in-reply-to:references:references; bh=7J/xNxyKUCJfUcM7Aa1hmRpPrNF7g6XA45P5a9ilEXs=; b=sqLtqTGgUS5b86D4GAC6qUCuuHWCo8+yLf5IZfJHg+Yi0dDaINth76UEBIjnwHvPJ3He5R P3cDvhSIqkayM/m97K5TGuQWQKn6i+w/0pEPgYQXohwscWJ2o5aJiOFfynoXi4otspxhsM ++v8k4/FlQ4rtfnNLBN/rhI75Lvz7USjK0tQzQcNPucHJuBBVF+iZWLeZgi6tu4Qcm+Gm0 GHyiG8sWtTAb0TwHMPwoBeyGKiYt3PdRfZX49dROgfmFu8V8G89JVPMff17Nb+R68yn180 M7aIMMBGfv4L/95fnwMji3vkVxG+io3MouTpVYDghN6WadrrtODOWXRU1cNfeA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1734478210; 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: in-reply-to:in-reply-to:references:references; bh=7J/xNxyKUCJfUcM7Aa1hmRpPrNF7g6XA45P5a9ilEXs=; b=H4+2XpydOUygRGKQ98O7dZTQbwzbX3fug3Rqc1s2y7OW1s10L2vfJmUIbJv04vptP8qA4V 27EFLONj7zm/rQDg== To: Atharva Tiwari Cc: evepolonium@gmail.com, Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Peter Hilber , Lakshmi Sowjanya D , Feng Tang , Marco Elver , "Paul E. McKenney" , Randy Dunlap , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/tsc: avoid system instability in hibernation System In-Reply-To: <20241216103735.2097-1-evepolonium@gmail.com> References: <20241216103735.2097-1-evepolonium@gmail.com> Date: Wed, 18 Dec 2024 00:30:10 +0100 Message-ID: <87ldwd7urh.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 On Mon, Dec 16 2024 at 16:06, Atharva Tiwari wrote: > instability are seen during resume from hibernation when system is under heavy CPU load. this is caused by the lack of update of sched clock data Neither the subject nor the change log text make any sense. (formatting ignored) Aside of that you still have not answered the question from Peter: https://lore.kernel.org/all/20241210123516.GP8562@noisy.programming.kicks-ass.net and you keep resending the same patch over and over without any explanation about the underlying problem. Actually after Peter asked you to provide details, you reduced the information in the changelog and resent the thing twice within a few hours. The second time with a even more broken changelog. Then five days later you repeat the exercise with a resend of the second variant. May I ask you to read Documentation/process/* to figure out how this works? You can resend this as much as you want, as long as you don't provide answers to the questions asked, this is going nowhere. Let me ask you more detailed questions: > +static int tsc_pm_notifier(struct notifier_block *notifier, > + unsigned long pm_event, void *unused) > +{ > + switch (pm_event) { > + case PM_HIBERNATION_PREPARE: > + clear_sched_clock_stable(); This marks a stable sched clock unstable, which means that the simple fast path of reading the clock: sched_clock_noinstr() + __sched_clock_offset; is disabled and the system has to update the sched clock data for no good reason. Questions: 1) What has this to do with heavy CPU load? 2) What has this to do with the system not updating sched clock data, especially as a stable sched clock does not require any sched clock data updates at all? 3) Can you provide dmesg output or any other evidence which backs up your reasoning to mark sched clock unstable when preparing for hibernation? Thanks, tglx