From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (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 DE50B3FCB11 for ; Tue, 21 Jul 2026 01:44:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784598254; cv=none; b=QASQ6iKFijh+llK2LXloAJOCYMuYtreWEdwBOQZAzUmEzDFD+zF9eOXnSBDfiE968DXM1LYCwns3LgBjK6B5dg7uPVAKiabtagcpzkxGyl/aNNqiC1Kn4DYIc8WnXVRfDmg625/YFD7gkuEnutzo7x4mXhAPUP1Xqp5dOj28k4A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784598254; c=relaxed/simple; bh=ilevQ6bwsQLzh3JOzjacrhtuo5GRlSwbuOUHgEo4Mkg=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=G53pSkkuhGiiGXZeAGJL2k74htA8rRqRHSD59opyXfuIvT6hIxBbBm8vmBJDyst0OQZTGtRWfcSMoy8CHKvAG55Pl+sVw4j6TlsRl18MF4aZ+eJCZBEzPEDPEwZEchzWebtanYh26KtgASwLHSBoJLbv6z3gb0jCjVct0Dx5olk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=VeY/KVCW; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="VeY/KVCW" Message-ID: <6b74b3cc-849a-4a0b-8971-e591f6ca3dca@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784598239; 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=qP7GoR0yPXAUHlXfNNC43mw+8vkPdP3SqsgqwzlleZY=; b=VeY/KVCWjc9tx69DMreZ9TjyiVowIoVhcWQXCWRR8dOGiPYN9Zc2QUmrBSEPT2hxKL2eDM ajeJR7FI9VEGWt7eE8/evaUUTlFfnVEi2iRCYoW9a2J8xyMs1BCc0gszCdgRFe1NNeRggV lhVaHj52nTqqTA8akzGDbBmiGwe/OHw= Date: Tue, 21 Jul 2026 09:43:51 +0800 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Cc: cui.tao@linux.dev, cgroups@vger.kernel.org, Tejun Heo , Johannes Weiner , Jonathan Corbet , Shuah Khan , Joshua Hahn , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, cuitao@kylinos.cn Subject: Re: [PATCH] cgroup/cpu: document cpu.stat nice_usec and core_sched.force_idle_usec To: =?UTF-8?Q?Michal_Koutn=C3=BD?= References: <20260718080100.2334415-1-cui.tao@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Tao Cui In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2026/7/20 23:26, Michal Koutný 写道: > On Sat, Jul 18, 2026 at 04:01:00PM +0800, Tao Cui wrote: >> From: Tao Cui >> >> cgroup_base_stat_cputime_show() unconditionally prints a fourth base >> stat, nice_usec, in addition to usage_usec/user_usec/system_usec, and >> also prints core_sched.force_idle_usec when CONFIG_SCHED_CORE is enabled. >> Neither field is currently described in the cpu.stat section of >> cgroup-v2.rst, which still states it "always reports the following three >> stats". > > Just to better sense popularity of the fields -- have you found this out > by: > a) reading cpu.stat and being confused about semantics of the fields or > b) scanning files/code vs docs looking for discrepancies? > (b). I found it while auditing the cgroup cpu controller, comparing what cgroup_base_stat_cputime_show() prints against the cpu.stat docs. nice_usec is emitted unconditionally but not listed there, and the "three stats" count was stale. The audit is groundwork for a prototype daemon that monitors per-cgroup resource usage and adjusts limits dynamically. The design is inspired by DAMON, but DAMON targets a single resource domain, whereas container workloads need coordinated control across several (cpu, memory, io) — which is why I'm going through the per-controller stat interfaces. Thanks, Tao > Thanks, > Michal