From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A52392D3EDC for ; Tue, 15 Jul 2025 06:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752560918; cv=none; b=sCJGeIoyzpcOcep6k4bonb9QYR6WSlnS4YWU5iPTfOjfgI9jZHrHOw0RNFpJiEQx3QdhG8MU1D6UjrJ1dsNx3VR+TddCN+8cncDgyRZ6dNhDPWPzFkzchdOVrcFKYxghJh/RpiiOea5L73j/8RocIgUtC+N+DZLke4wIHlPHpJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752560918; c=relaxed/simple; bh=hzBhaj0bPfBfH8WKXsSODcE4YTYKjXAXkYFweZnaSTw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ks4IModBMfk1FXLGiasBqskOFm4BFnfg6buUX+wob0N9/+K6LHKf8PVFlzy7djV613UNXHcFEbIwCkQggNbwIrwkbkSDnCTa3I+W6MlO3kpIfSeyNMsdesahJPvKnd21hOa8I/8quy8BjZlrhIrl74nqwi1DMN8OM1Lmui1Fflk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=KIFPa5v1; arc=none smtp.client-ip=209.85.160.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KIFPa5v1" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4ab3ad4c61fso259951cf.0 for ; Mon, 14 Jul 2025 23:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752560913; x=1753165713; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IIFY6igA7ItbPWoIp1wqanVGqlzkgUCSQp6wKLEinNo=; b=KIFPa5v1yzEOMUWc2oN3k4lDin08bHuedvs0R+MBycdm+X3PxNHHkj/3pfKcan15ie ozuO1URQu7Qez3uJxidG4ZbSlrOaYacxdHk1XaBHVtQFxr3NGsI6KwsY/KJKoqmIKKgZ lTWCxWd5nrPTRBp69m5XUbsByJ3KSSqno9weyJo0voZKCEXte4qwyXFhyF4cGml5q2V5 z431YKXtSnZoe5Gwt47JM6HCu7gqDfvFi3FMj8ZNy02wjkkGXaG1MlA0zzYWNDILRuzD AmMH8H0PL3DBJHzDRUiemWdUxNXJZo3vnvQL8ggBUqD0CHSMRVdxswHK9DiVcUNF5fli CFcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752560913; x=1753165713; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IIFY6igA7ItbPWoIp1wqanVGqlzkgUCSQp6wKLEinNo=; b=Pj4IjViDgXxxa7qAbCIdtmnRik1VQnFx4j/6CXHTIz9NzNUXaDdVsicem9KEPUnyl1 8U8D6aVXqKiuZp4EiboVYL0k26NIOtifLRIlFu0yQQBkABjoyX6JU5MTSrgDUD+WCmoZ EyHlvdOK5LQg0H+BZwUS51GowOVD2HhzuyIv0Oth+DIs+qy2FmVBKIt9VUYStj7B2g5g uhJP71F/xfTTu/f5dTGIa/A7pbCKLJvW0uZdvJriL3Uv2rXk+0IhBrmNFBwX9YIZpMl1 9nyMjYENFITo5GnoTzWAZreZvEv/aYwhGb+t+XJ21zpJ392yZjk5EUlklIStxcDJCfs2 hO5Q== X-Forwarded-Encrypted: i=1; AJvYcCWMNuY77IBRmwz+SnVdhWEWqhoNMCPrJz7L6Fbwb57JNxcCbGd4gyFwmQC9lUYg2xHRLrE/uQH0BwsftKU=@vger.kernel.org X-Gm-Message-State: AOJu0Yyuq+pAl/+FwJJsqNTE0Tu+XtgpRe7daUSVJogVvu8NoVwvTFqf EuUdQqkIjR1U6Wxn1d/68uXdXmu1ZZn6liDa8N5jL5tJx4/KeEbrE6CUq2+3jXf2S5EfqCjbQUa nb6BuRtFn7xu1tMHbKWdf3UQS2tMPPWGfUcaGODxS X-Gm-Gg: ASbGncszptm4itRLYEazVUxyXVyxbQrVw3aS/63wl7gGzdoaNBSFCjILC4CpBz2POom ug9PAbLUlAz8wgoCzi5NA+g6D3tGKHJIe5YP3uMJAv4vsjIUTm+WO/ELRQLihNGr0WVJ8doM6NV VKb4bm8+TfJQZ7w5ljtQf8SWZc5UVjbxV/fliYYfpQ68asTWve0HKz7Drm/eDzZXWMHCSIYVJX1 jujJlkfsUwymZ/+ X-Google-Smtp-Source: AGHT+IGbMIrszzxiU6KwxjeVl8dXHdRHJ+aTFTtAE8A5hcOifW7wZve3PV5GRWnbvGMzyczeFNNWqNJ4uzW79JPmRIs= X-Received: by 2002:ac8:6909:0:b0:4a9:d263:d983 with SMTP id d75a77b69052e-4ab80cc6f95mr2983331cf.22.1752560913237; Mon, 14 Jul 2025 23:28:33 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250619000925.415528-1-pmalani@google.com> <20250619000925.415528-3-pmalani@google.com> In-Reply-To: From: Prashant Malani Date: Mon, 14 Jul 2025 23:28:22 -0700 X-Gm-Features: Ac12FXz0toYZ_F0QSp7PcKhcRht-0rDhzIAHVwCuSAtnjh8CuP5L2iqWPl5spU8 Message-ID: Subject: Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs To: Beata Michalska Cc: Jie Zhan , Ionela Voinescu , Ben Segall , Dietmar Eggemann , Ingo Molnar , Juri Lelli , open list , "open list:CPU FREQUENCY SCALING FRAMEWORK" , Mel Gorman , Peter Zijlstra , "Rafael J. Wysocki" , Steven Rostedt , Valentin Schneider , Vincent Guittot , Viresh Kumar , z00813676 , sudeep.holla@arm.com Content-Type: text/plain; charset="UTF-8" +Sudeep. On Mon, 14 Jul 2025 at 02:31, Beata Michalska wrote: > So I believe this should be handled in CPUFreq core, if at all. > Would be good to get an input/opinion from the maintainers: Viresh and Rafael. Viresh, Rafael, Sudeep, could you kindly chime in? The unreliability of this frequency measurement method in CPPC is affecting the cached frequency saved by CPUFreq, which in turn affects future frequency set calls. It would be great if we could solve this in CPUFreq core (maybe not rely on the cached frequency while setting the new one [3]?) > > In the meantime .... > It seems that the issue of getting counters on a CPU that is idle is not > in the counters themselves, but in the way how they are being read - at least > from what I can observe. > The first read experience longer delay between reading core and const counters, > and as const one is read as a second one, it misses some increments (within > calculated delta). So, what we could do within the driver is either: > - Add a way to request reading both counters in a single cpc_read (preferable > I guess, though I would have to have a closer look at that) I already tried something like this; I used [1] which basically puts the 2 (constcnt, corecnt) register reads in a single CPC call; This did not help. The values are still highly variable. I never got merged FWIW. > - Add some logic that would make sure the reads are not far apart As Jie pointed out earlier, a lot of this has been discussed (see the references within the patch link [2]), so I'm not really sure what else can done to reduce this on Linux; there are two registers (SYS_AMEVCNTR0_CORE_EL0 & SYS_AMEVCNTR0_CORE_EL0), so there will always be some scheduler induced variability between the two reads. Best regards, [1] https://patchew.org/linux/20240229162520.970986-1-vanshikonda@os.amperecomputing.com/20240229162520.970986-4-vanshikonda@os.amperecomputing.com/ [2] https://lore.kernel.org/linux-pm/20250131162439.3843071-1-beata.michalska@arm.com/ [3] https://elixir.bootlin.com/linux/v6.15.6/source/drivers/cpufreq/cpufreq.c#L2415 -- -Prashant