From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 789EFC433EF for ; Wed, 27 Apr 2022 07:23:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347148AbiD0H0U (ORCPT ); Wed, 27 Apr 2022 03:26:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236000AbiD0H0T (ORCPT ); Wed, 27 Apr 2022 03:26:19 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B931C3389C for ; Wed, 27 Apr 2022 00:23:08 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1651044187; 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: in-reply-to:in-reply-to:references:references; bh=dWtbS5lg1a9gM/YQcx7iEZL/3leG2VJ+qMbbrkRFwgE=; b=aAUQMbdksTR0gvdDY+Qt2OIL4QBVYOdTBvBWDhAZhxGAOZMQRL6f4JJconDCX4PFYkt+a0 qBdR8hWwf/HR39Chqy7J3OnutXKJEXnAyhrU0jLSCgX/ir/yREAp0r3SG9LK8d349DkWlH gZbmxOf4wAmRYgzczv6A6gqOyPqCvUZQ+ZGyNXCoFXI0tlANvUaQJCYU06O7PDZLLKGe8l 7OwsYOvu9XLtEYyJECmWMF/BDs2+ffKQQJacZ0tBy6p7Fyew2m+sNHpuD0BAvSf5uo2i1I zOPbxZ6rxt3vJW9G29c2f+PFnvkgQPpEcbD44tFuw+O7BUZe3W2zY0hbQF13BA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1651044187; 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: in-reply-to:in-reply-to:references:references; bh=dWtbS5lg1a9gM/YQcx7iEZL/3leG2VJ+qMbbrkRFwgE=; b=Et3zD8l3ok5Xr2j3fnO+TSQb0Cuvg4zWjtLZPZ7Rz+tNLnYjrInS/Oc4Qo156HoNF8gjID 95FKkkl5VMqYzyDQ== To: Marcelo Tosatti , linux-kernel@vger.kernel.org Cc: Nitesh Lal , Nicolas Saenz Julienne , Frederic Weisbecker , Christoph Lameter , Juri Lelli , Peter Zijlstra , Alex Belits , Peter Xu , Daniel Bristot de Oliveira , Oscar Shiang , Marcelo Tosatti Subject: Re: [patch v12 12/13] mm: vmstat_refresh: avoid queueing work item if cpu stats are clean In-Reply-To: <20220315153314.287031403@fedora.localdomain> References: <20220315153132.717153751@fedora.localdomain> <20220315153314.287031403@fedora.localdomain> Date: Wed, 27 Apr 2022 09:23:06 +0200 Message-ID: <874k2fyopx.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 15 2022 at 12:31, Marcelo Tosatti wrote: > /* > * The regular update, every sysctl_stat_interval, may come later > @@ -1948,9 +1977,19 @@ int vmstat_refresh(struct ctl_table *tab > * transiently negative values, report an error here if any of > * the stats is negative, so we know to go looking for imbalance. > */ > - err = schedule_on_each_cpu(refresh_vm_stats); > - if (err) > - return err; > + cpus_read_lock(); > + for_each_online_cpu(cpu) { > + struct work_struct *work = per_cpu_ptr(works, cpu); > + > + INIT_WORK(work, refresh_vm_stats); > + if (need_update(cpu) || need_drain_remote_zones(cpu)) Of course that makes sense in general, but now you have two ways of deciding whether updating this is required. 1) The above 2) The per CPU boolean which tells whether vmstats are dirty or not. Can we have a third method perhaps? Thanks, tglx