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 9D9713D3D13 for ; Wed, 1 Apr 2026 15:52:57 +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=1775058778; cv=none; b=K/WFNRqQaPw6KVZrdGnsyhz5E97BfQ1EpElrDSQXsMKu8S36YkUHFLQAVlgBmq2QC2M7L4MvyoLOUwi4Z+iRc+GGvWx/mJKLIBQJXRVz8VXjXva5GKu4IQCe7kKAEIfIRfLcuiPzgCHmPhM9/47/bHWioZxBxcXUhvSvVNJgkEM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775058778; c=relaxed/simple; bh=AXu0oOXgioW4SALKegP9Xexx5exPsl89G35/f0YRRHg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Do2DJrEzxhv+tNlEAL/zK24/Fpr9km5qomcbMIO4BhMn9rShOur3lrgkuWLjwijkixbxkZDf7DmbM1dZvYz/ds/mPxP2GUi3i9EkiWu53FFCkHufdKkaiHXBeXUkX+RmKqSZ0HfaXv1W9GNjuT3PE2Aav01HbSFqO8aDlW66CRM= 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=PabF1i/o; 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="PabF1i/o" 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=Xpk2KqHsKd8WkdQw/hVd0mcmOtkvgHESF7Hs9H3tAtg=; b=PabF1i/o+ZJiHqJ+M/BVARG8ZC xJK+r/BlIFxBeexlys85rDUFrrTRjg8xRIcVMJSnTBw42KKu31nLD20u+E2JWBAH7AxLIoXOA11+M lZUbAv0zDsU3rFPCu6iDYDbLegbUdQS8k45f0LsNmUPiSd1SsbHl57cPp/k0lZiWdJLiuzkMln9hw IL9Plu9r3sL0uI/dGhEEdYwL6/5rP+0xLY0Sm3Bht9j1A8ycZ/Mx/78osTpZVUa4N3yrNWz1WBFoy MWNqeW/4XQdwD2n/IqmjWFHj1cD5HQEacj73cFeC0rtnH4C7n+/6Zdd70UVtq8GdhTvVIQpld/JhV e3Rmbd6w==; 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 1w7xs9-0035ru-2w; Wed, 01 Apr 2026 15:52:48 +0000 Date: Wed, 1 Apr 2026 08:52:43 -0700 From: Breno Leitao To: Usama Arif 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, 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> <20260401152343.3294686-1-usama.arif@linux.dev> <8ede5e20-9309-4d1a-8f12-13603fd92014@linux.dev> 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: <8ede5e20-9309-4d1a-8f12-13603fd92014@linux.dev> X-Debian-User: leitao On Wed, Apr 01, 2026 at 04:50:03PM +0100, Usama Arif wrote: > >> > >> This is awesome! Maybe this needs to be done to vmstat_shepherd() as well? > >> > >> vmstat_shepherd() still queues work with delay 0 on all CPUs that > >> need_update() in its for_each_online_cpu() loop: > >> > >> if (!delayed_work_pending(dw) && need_update(cpu)) > >> queue_delayed_work_on(cpu, mm_percpu_wq, dw, 0); > >> > >> So when the shepherd fires, it kicks all dormant CPUs' vmstat workers > >> simultaneously. > >> > >> Under sustained memory pressure on a large system, I think the shepherd > >> fires every sysctl_stat_interval and could re-trigger the same lock > >> contention? > > > > Good point - incorporating similar spreading logic in vmstat_shepherd() > > would indeed address the simultaneous queueing issue you've described. > > > > Should I include this in a v2 of this patch, or would you prefer it as > > a separate follow-up patch? > > I think it can be a separate follow-up patch, but no strong preference. Thanks! I will send a follow-up patch soon. --breno