From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) (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 04AE3437117 for ; Mon, 20 Jul 2026 17:05:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784567145; cv=none; b=Pt+9ZekxBRcRDMK1SPUP44u4AJi1kizBxoV6tih6h+As/2PKGNX/7csdtXQZbrS6UxaIv913fkKhdDM6zPPoC6g0ySwk4IVlQ+Q8NrfjSnY7ArCACjeEnDd8OI4zg5Av1qigDhYg1x4ePdwxNVsvxTJ6vZ+5w3qt1xSx9pm084E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784567145; c=relaxed/simple; bh=EPHXgE92OZtwrusVZTpJimPa6PHp1mjxA6Q2dzygXUs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uWOy/Ct6LV681DQ5yY2w4w6YA2mZ+1wOY+HlGRLArUPEZKPJKw9JfIiHG5czHxtSNoVtnLLdqILfwOyyLE0/7jebDtTbImazrQ8tZejlls930YFmyQnPwUUFYQStefVprCGfFz13MtYzW72HSKLV6q9wvTd2T9e/+EPFqAKO9J4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FO5m1tKv; arc=none smtp.client-ip=209.85.128.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FO5m1tKv" Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-81eb41c1f1aso83479227b3.2 for ; Mon, 20 Jul 2026 10:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784567138; x=1785171938; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=GqlMGabo3ObXGmn0thsIH4WBoZJD0hx7su/ezzAUMj8=; b=FO5m1tKvKY/aP9evleF+whRzKapro7xwpXTfGXXNFizkcZTJJYzjp7TrdtyJpzms44 wEGW2ZSDLx2S2MiuDVvCk8mnjw/9LYB7guNFDmTc98T6KeIw5Zkd/f66x21agGOP8vry PovdbWeDQP3x+5VmgeCTa6UGAq4ANHuXSzvk6csHEpJNYDqFVYt6l9G+cAfj8RDzIunb Su7DWx3/CycylC+5AaLNtrwMDvbYMDdFmLddLDVLrsVdtcwiczCMsbgYdwLtlx4XtWdi 3GILtvxicmAALWa0xztdyfuSXYXS0w/qc0ANr5jAvgXxedXmG7ptBY0fwtDISIKwezA1 y9qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784567138; x=1785171938; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=GqlMGabo3ObXGmn0thsIH4WBoZJD0hx7su/ezzAUMj8=; b=pDrhFCnD2j7YGgCpvr2AyZm0wuRhYAdZ4J5VURsyQ4NVamOPDGD2sToeULxTjBnvSR vpvWf4Kx+wVlEIA2ljrH5UfgbF07cxr3xIt0FWZ9Ou0rgCjdta8nNEWbnqEtrDJNdIya cVB5dv88QWuktJXx0GFODl3mBZ61bHDxxfngr/QYnUNr8WOftkoDv4XDNkCIXe1b8s67 I6qw4C7SGh4b0nLhueAtpvY5x+wh3K4Rj3FWxSeWFu622a0uFi17pexzOEZvZDwmXG6W dSaXInixemZxcZGMnF0oPQK+OsXbvTRDZT+TszltWGwf9H2fOCJlWy93vO/nklbspcqX MsXg== X-Forwarded-Encrypted: i=1; AHgh+RqBoc8ZiWhnn6XJoAF8PXWkT2eEPlZunX2claeAuRs/6Vgfr8BDSwWkY/bNCQjNBYjaXB/C61IDeWqLHIg=@vger.kernel.org X-Gm-Message-State: AOJu0YwqH8cJHlqFE9FKZlauNR14Or/EX1tp2vpaAxgfG1QNp2GeTXSq xYbDgb8Y8IVV43BshS96xqfRoJMx6Z8oiYsBJu+0bngP0g9VUufKQ4rD X-Gm-Gg: AR+sD12phWYJxR2Iq5eNzeWqtko7qp3SQBqLXeDz3nsfwqgVpkJy+g1KAi7DZ1zm0im 4GyXiwHfEmXSccQBanH6QHQ5W1/5Ek4aGVsPFjtK0XKiYR54y9V8ImNNN85yT3wZZ5edrWfeFPc RZSVtaNXcfCWcWPfHObEGdyo3CjNuPyTIfaYkdEdwzfWL+abjfnUKmIRURXP7bAJFoKuxC8Nxtu 5R17uHknwo+kDYg+SCzdkH8RKQMqWLe71lF90qORRNc9fHz4zW9T4Ac+XhgglEOVEP7o5tY9g5E 37VBoeotk7FoxYw2WGdGWmUqNcL5MT3zqznxhVXs0dKvvoxsHkL5UlgTXSkNFuD0fFQyGUkEHeo NC1Bl1XOqE3wZZ+zUhGLlE1bnoT54HKsI5NCR6tub1DGhVCcCoLoPi9ZgauJL89F7EhGl2xXgvw Puu8IIsuyN6orh60Qr+mHJ X-Received: by 2002:a05:690c:4b0a:b0:80c:5ce9:8f1a with SMTP id 00721157ae682-81ef27f1ccbmr48967227b3.34.1784567137799; Mon, 20 Jul 2026 10:05:37 -0700 (PDT) Received: from [192.168.0.23] ([210.10.76.89]) by smtp.gmail.com with ESMTPSA id 00721157ae682-81ef4034901sm53073037b3.12.2026.07.20.10.05.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2026 10:05:37 -0700 (PDT) Message-ID: <296cbf18-86da-4c1b-832d-a27a78881dd8@gmail.com> Date: Tue, 21 Jul 2026 01:05:31 +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] block/blk-stat: fix mean loss when re-summing aggregated stats To: Tao Cui , Jens Axboe Cc: Tejun Heo , Josef Bacik , Omar Sandoval , Bart Van Assche , linux-block@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Tao Cui References: <20260720133813.45150-1-cui.tao@linux.dev> Content-Language: en-US From: Tang Yizhou In-Reply-To: <20260720133813.45150-1-cui.tao@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20/7/26 9:38 pm, Tao Cui wrote: > From: Tao Cui > > blk_rq_stat_sum() folds src into dst but only advances dst->mean and > dst->nr_samples, leaving dst->batch untouched. The mean is computed > from src->batch (the raw per-cpu sum), so a stat that has already been > through one sum carries batch=0; if that aggregated stat is then used > as the src of another sum, its samples add nothing to the new mean. > > iolatency hits exactly that: iolatency_check_latencies() first sums the > per-cpu stats into a local stat, then sums that local stat into > iolat->cur_stat. After the first sum the local stat has batch=0, so > every later window drives cur_stat->mean toward zero. On non-SSD Good catch, this is indeed a real issue. > devices it stays at 0, making the latency_sum_ok(&cur_stat) check that > gates scaling up always true -- the scale-up hysteresis is effectively > defeated. SSD devices use the percentile path and are unaffected. > > Keep dst->batch in sync across sums so an aggregated stat can be reused > as a src. blk_rq_stat.batch is internal to blk_rq_stat_init/_add/_sum > (no other reader in the tree), so the wbt and blk-mq consumers, which > only read ->mean/->min/->nr_samples, behave as before. > > Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting") > Signed-off-by: Tao Cui > > --- > block/blk-stat.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/block/blk-stat.c b/block/blk-stat.c > index de126e1ea5ac..4d4781350083 100644 > --- a/block/blk-stat.c > +++ b/block/blk-stat.c > @@ -36,6 +36,7 @@ void blk_rq_stat_sum(struct blk_rq_stat *dst, struct blk_rq_stat *src) > dst->mean = div_u64(src->batch + dst->mean * dst->nr_samples, > dst->nr_samples + src->nr_samples); > > + dst->batch += src->batch; This change doesn't actually fix the issue. As you already found, the local stat's batch is 0. Also, according to the comment of blk_rq_stat_sum(), @src is a per-CPU stat, so there is no issue in blk_stat_timer_fn(). Your change would actually make this case look strange. -- Best Regards, Yi > dst->nr_samples += src->nr_samples; > } > > -- > 2.43.0 >