From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 C721A5B1EB for ; Wed, 28 Jan 2026 02:19:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769566769; cv=none; b=JRmNQ0HN049+Gz/Las0EKj0RBxEy2HusPgoktnx+mxrcDmcXkEyhA+EbWO9mFsabsBwpTeyhTddxro9zuzBbYwcqGVgK5122CMfYjkApOosXxTZkmczZh5WTJ/fXCPrAD0K8sPNFDEqoqVATcXHZ1aJbtdrM8FpwCli9v4yE76g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769566769; c=relaxed/simple; bh=9ThrWOIbXyIg56bDvefcV4oKxqOdMr/OMV1o1FJnb+0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=r8flwWigRJclr3tHb5C5+NIhxPRPK5A1Uf2EsefpTnJ7WTixFN1ZLzyigbUN1DjiWz/lGG47I2REz7NyDXkaj3YaD5K+UBdBbEOB+r2Qy/rwQmDoFWGRZU556IXPCSCHsnx3zH7ZrCycQ5JqDN3ITrGIE4NsNhnazck44AVi5GQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TfOTLCbB; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TfOTLCbB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769566768; x=1801102768; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=9ThrWOIbXyIg56bDvefcV4oKxqOdMr/OMV1o1FJnb+0=; b=TfOTLCbBsR16mp6P5zauS8BLJddE8H+2iMFTnz1ruDIVCyqolSzSpCzr TLKMQW/AYRaNxEUSrjTh1G65Fk4utk7yU9LpOxSBpTEMjdTm09TMOyf/1 BK1GxJLmRYlqPJPik+2y3mgQbIFwCDykqH9/BC/N2j7c/Q8VkYi8LXqB0 DJhmrup7l53H3kHn+BZE4w4sOf5L14lEyWriqx9LaKHbU4o0lRwECMAx6 pJ4VXz7FpOH+brqcLExddfOICWMy2Q1afVwhudeEA5u6z1PXVPdhkymwg SOPqEWbTa/W2QlDIW6/QAQaQjXMp63SD6yVvh4L+gA8MUBqJrm2+5LR2U Q==; X-CSE-ConnectionGUID: coWXTDcZQjG+soMZwwo00A== X-CSE-MsgGUID: 9ZLLUxt3RwKC4IbUarr2LA== X-IronPort-AV: E=McAfee;i="6800,10657,11684"; a="70747525" X-IronPort-AV: E=Sophos;i="6.21,257,1763452800"; d="scan'208";a="70747525" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2026 18:19:27 -0800 X-CSE-ConnectionGUID: +WLZLJUnRzankdpM2+9COg== X-CSE-MsgGUID: wc+WOX1dQeesRaUquv7Qnw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,257,1763452800"; d="scan'208";a="231092306" Received: from unknown (HELO [10.238.1.186]) ([10.238.1.186]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2026 18:19:24 -0800 Message-ID: <3b69443c-f82c-4b73-8384-2a039d730213@intel.com> Date: Wed, 28 Jan 2026 10:19:21 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7] sched/clock: Avoid false sharing for sched_clock_irqtime To: Shrikanth Hegde , K Prateek Nayak Cc: linux-kernel@vger.kernel.org, Benjamin Lei , Tim Chen , Tianyou Li , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider References: <20260127072509.2627346-1-wangyang.guo@intel.com> <7c6236a5-82b7-4d1b-9bb2-3f0d2ac186f8@linux.ibm.com> Content-Language: en-US From: "Guo, Wangyang" In-Reply-To: <7c6236a5-82b7-4d1b-9bb2-3f0d2ac186f8@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/27/2026 7:04 PM, Shrikanth Hegde wrote: > Hi Wangyang, Prateek. > > On 1/27/26 12:55 PM, Wangyang Guo wrote: >> Read-mostly sched_clock_irqtime may share the same cacheline with >> frequently updated nohz struct. Make it as static_key to avoid >> false sharing issue. >> >> The only user of disable_sched_clock_irqtime() >> is tsc_.*mark_unstable() which may be invoked under atomic context >> and require a workqueue to disable static_key. But both of them >> calls clear_sched_clock_stable() just before doing >> disable_sched_clock_irqtime(). We can reuse >> "sched_clock_work" to also disable sched_clock_irqtime(). >> >> One additional case need to handle is if the tsc is marked unstable >> before late_initcall() phase, sched_clock_work will not be invoked >> and sched_clock_irqtime will stay enabled although clock is unstable: >>    tsc_init() >>      enable_sched_clock_irqtime() # irqtime accounting is enabled here >>      ... >>      if (unsynchronized_tsc()) # true >>        mark_tsc_unstable() >>          clear_sched_clock_stable() >>            __sched_clock_stable_early = 0; >>            ... >>            if (static_key_count(&sched_clock_running.key) == 2) >>              # Only happens at sched_clock_init_late() >>              __clear_sched_clock_stable(); # Never executed >>    ... >> >>    # late_initcall() phase >>    sched_clock_init_late() >>      if (__sched_clock_stable_early) # Already false >>        __set_sched_clock_stable(); # sched_clock is never marked stable >>    # TSC unstable, but sched_clock_work won't run to disable irqtime >> >> So we need to disable_sched_clock_irqtime() in sched_clock_init_late() >> if clock is unstable. >> > > Do you this as a valid case? have you tested with CONFIG_PARAVIRT? > > Lets say you have a non native sched clock such as kvm_sched_clock_read. > tsc_init -> sets enable_sched_clock_irqtime() >          ->mark_tsc_unstable -> if using_native_sched_clock -> > clear_sched_clock_stable > > In this case, since clear_sched_clock_stable won't be called you may not > disable the > sched clock irqtime since __sched_clock_stable_early is reset only in > clear_sched_clock_stable For hypervisor, I see this path may call clear_sched_clock_stable when clock is unstable at init: kvm_init_platform() -> kvmclock_init() -> kvm_sched_clock_init(stable): if (!stable) clear_sched_clock_stable() paravirt_set_sched_clock(kvm_sched_clock_read) > > Bigger concern(maybe) is clock source marked as stable still, though > called mark_tsc_unstable in > non native sched clock? > > Disclaimer: (just curious, seeing this x86 code for first time, so may > not know all paths) > Yes, when clock mark unstable through tsc_.*mark_unstable() with non-native_sched_clock, clear_sched_clock_stable won't be called, thus sched_clock_irqtime still keep enabled. Maybe the dedicated workqueue for sched_clock_irqtime is still needed considering this case.