From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 1560B2ECE9B for ; Thu, 2 Apr 2026 13:33:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775136813; cv=none; b=VM7JPVLm53AnIdI3U2GLAouRtrO9DmtYDDHXWZElH/6+Spoa2dZg+D5ElTqYwQrVL9V7Ut1QAIFBsvsIML6BAXigdN6xEP6Zrp59iDXa40XcyRxvPsX96vWiNnhuhNaTVPcOONw9/gsXZyD8M2oggtbUkkfJc66D4s5OfhpqsG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775136813; c=relaxed/simple; bh=d2RB51Unwy/SFtFZ2Hwl5cQhST25DDDlXgHC4Tzefwk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=im4RZ3EYy+WD9tE8/u4ArzmeRUcbdGThLq6Nx6ozGtsMciJQSpP5VN3GShyEjuADAe3qzlvC/OqxlP01aIYl5Ye6gFJdo6udenohNJLE3dgcKId7H03X/tvUPb3LRtUSgSUfM24ETC0yWNyBVc9ZkWDp/tNcyiDn0p9nXxrTUU8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=iR6thK/Z; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="iR6thK/Z" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mXyOffJoj0vx+EAUo0TPbuyn0MsrVCVYwm7k2LD6NB4=; b=iR6thK/ZdwjgK0rBw2kjZfO7Cb Q8I5RMdOlfyerfFcG/qmotSlAa2KUkvL8qU/LQhRcbQWOo5mmVfQVcUoCMTnNUSNGb6qOwOpxDYZ5 rYUqGFOoixppN4JTIJ+ypg01OZckpJHQXH18aZdekUJ/J8hMmQ979x0vNZ6WacqW+TvltAZzXGSja 6s2k+QtWd+dPpo6mT92ptbvvOA6/O0Xqn7YfP2AOmqge3h/snaWu3RMKGxD4lbdOWYqqJNfeQX3rl LFxqXaALOBADek5BmQGfRbGsc/u4N/L4iLoLvcgC/ynKAQDKu2Sl2CbLV6b09UzUFHyq9yvJ6x0KC I5yy/BSQ==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1w8IAl-003nZv-1c; Thu, 02 Apr 2026 13:33:22 +0000 Date: Thu, 2 Apr 2026 06:33:17 -0700 From: Breno Leitao To: "Vlastimil Babka (SUSE)" Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kas@kernel.org, shakeel.butt@linux.dev, usama.arif@linux.dev, kernel-team@meta.com Subject: Re: [PATCH] mm/vmstat: spread vmstat_update requeue across the stat interval Message-ID: References: <20260401-vmstat-v1-1-b68ce4a35055@debian.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Debian-User: leitao > > > > Cool! > > > > I noticed __round_jiffies_relative() exists and the description looks like > > it's meant for exactly this use case? > > On closer look, using round_jiffies_relative() as before your patch > means it's calling __round_jiffies_relative(j, raw_smp_processor_id()) > so that's already doing this spread internally. You're also relying > smp_processor_id() so it's not about using a different cpu id. > > But your patch has better results, why? I still think it's not doing > what it intends - I think it makes every cpu have different interval > length (up to twice the original length), not skew. Is it that, or that > the 3 jiffies skew per cpu used in round_jiffies_common() is > insufficient? Or it a bug in its skew implementation? > > Ideally once that's clear, the findings could be used to improve > round_jiffies_common() and hopefully there's nothing here that's vmstat > specific. Excellent observation. I believe there are two key differences: 1) The interval duration now varies per CPU. Specifically, vmstat_update() is scheduled at sysctl_stat_interval*2 for the highest CPU with my proposed change, rather than a uniform sysctl_stat_interval across all CPUs. (as you raised in the first email) 2) round_jiffies_relative() applies a 3-jiffies shift per CPU, whereas vmstat_spread_delay distributes all CPUs across the full second interval. (My tests were on HZ=1000) I'll investigate this further to provide more concrete data. Thanks for the review, --breno