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 AD0E426E718 for ; Thu, 2 Apr 2026 13:27:24 +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=1775136446; cv=none; b=ElzlF6gCD+1GUf6tIOz8IlBo0ySszbCypy8UpFDvNJFZBxUJpnD74rFMk5EMGEenD5KyXaCCDaJxF2BRWfMZ6PBdVnsdS+Hvfo83/UVHMhKMQKhukekjKSIApOZg6c+IfQqP0meVSJzQjEgMSuWXT/UC6vBy767SgIOGVbXLtXk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775136446; c=relaxed/simple; bh=X+cu5pDbRCs2KdHAhHnjf75kgwmrLrIGJG71ygVpfZg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cvgowVpd3AvCqZFHSnLGsAboHZbiYill7Hz+Ml0K/LwpgvM0+QcarhbzRnOP2WdPg1Y5d7lrDtLF9b9+WnPGmK90josUau1ypFMRZhVXKWKCtGgQdk4AHrbbZPobR++n789OHmZZUcHp/zzMKX8Goy3DOltIVsEEeI80onyBe5M= 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=WQzXvC5U; 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="WQzXvC5U" 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=AdzKOxQ14nFM98WmcIU2Nw6FkbUtmbmQLtarAg5LvJQ=; b=WQzXvC5U4kKkengYyoy3/e56db 5XhOFTIn93mcIWLxbiaNfhlpaoA7/DfBvD3+dKxmQ2BeK0DJw1eGUesltdTYmVYVGBkM1ejORX0yt DFb829iyymGdDPX3kRQSVk0HTMmU6BDbQfHSsnP3L6C/fNxaNq08lHaxUG/ue5IJeQOTwqz1DvdF+ xYCGlpd+Kbtu1Ihpq6bcErhETwebjuILwvFeFjW9GIRaNoaT0k6ieu85Lt9iiJ9v6ia+V8J/Ddk6b 3iPVLnHCO5GCXe5lz3iQOjQKtn0rOCsg0/eRRmgBgbX0JRUlZ5Lf9AFoGDJfuZMhE/KVMyj+u2zXA Ls0veUbw==; 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 1w8I4e-003nP9-0M; Thu, 02 Apr 2026 13:27:02 +0000 Date: Thu, 2 Apr 2026 06:26:56 -0700 From: Breno Leitao To: Matthew Wilcox Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , 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 Hello Matthew, On Thu, Apr 02, 2026 at 01:49:34PM +0100, Matthew Wilcox wrote: > On Wed, Apr 01, 2026 at 06:57:50AM -0700, Breno Leitao wrote: > > vmstat_update uses round_jiffies_relative() when re-queuing itself, > > which aligns all CPUs' timers to the same second boundary. When many > > CPUs have pending PCP pages to drain, they all call decay_pcp_high() -> > > free_pcppages_bulk() simultaneously, serializing on zone->lock and > > hitting contention. > > > > Introduce vmstat_spread_delay() which distributes each CPU's > > vmstat_update evenly across the stat interval instead of aligning them. > > But, uh, round_jiffies_relative() is _supposed_ to do that! Look at > both the documentation and implementation. Why isn't it working? The documentation is a bit trick on me, sorry. This is what I read: "By rounding these timers to whole seconds, all such timers will fire at the same time, rather than at various times spread out. The goal of this is to have the CPU wake up less, which saves power." This is the full documentation: /** * round_jiffies_relative - function to round jiffies to a full second * @j: the time in (relative) jiffies that should be rounded * * round_jiffies_relative() rounds a time delta in the future (in jiffies) * up or down to (approximately) full seconds. This is useful for timers * for which the exact time they fire does not matter too much, as long as * they fire approximately every X seconds. * * By rounding these timers to whole seconds, all such timers will fire * at the same time, rather than at various times spread out. The goal * of this is to have the CPU wake up less, which saves power. * * The return value is the rounded version of the @j parameter. */ unsigned long round_jiffies_relative(unsigned long j) { return __round_jiffies_relative(j, raw_smp_processor_id()); } EXPORT_SYMBOL_GPL(round_jiffies_relative);