Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757375Ab3HHGyQ (ORCPT ); Thu, 8 Aug 2013 02:54:16 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:52745 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756062Ab3HHGyP (ORCPT ); Thu, 8 Aug 2013 02:54:15 -0400 MIME-Version: 1.0 X-Originating-IP: [212.179.42.66] In-Reply-To: <0000013f61e7609b-a8d1907b-8169-4f77-ab83-a624a8d0ab4a-000000@email.amazonses.com> References: <1371672168-9869-1-git-send-email-gilad@benyossef.com> <0000013f61e7609b-a8d1907b-8169-4f77-ab83-a624a8d0ab4a-000000@email.amazonses.com> Date: Thu, 8 Aug 2013 09:54:13 +0300 Message-ID: Subject: Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional From: Gilad Ben-Yossef To: Christoph Lameter Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Frederic Weisbecker Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2066 Lines: 61 On Thu, Jun 20, 2013 at 5:05 PM, Christoph Lameter wrote: > > On Wed, 19 Jun 2013, Gilad Ben-Yossef wrote: > > > +static void vmstat_update(struct work_struct *w) > > +{ > > + int cpu, this_cpu = smp_processor_id(); > > + > > + if (unlikely(this_cpu == vmstat_monitor_cpu)) > > + for_each_cpu_not(cpu, &vmstat_cpus) > > + if (need_vmstat(cpu)) > > + start_cpu_timer(cpu); > > + > > + if (likely(refresh_cpu_vm_stats(this_cpu) || (this_cpu == > > vmstat_monitor_cpu))) > > + schedule_delayed_work(&__get_cpu_var(vmstat_work), > > + > > round_jiffies_relative(sysctl_stat_interval)); > > + else > > + cpumask_clear_cpu(this_cpu, &vmstat_cpus); > > The clearing of vmstat_cpus could be avoided if this processor is not > running tickless. Frequent updates to vmstat_cpus could become an issue. I like the idea of tying the vmstat disabling to the tickless logic but I seem to have run into a bit of a chicken and egg problem here: vmstat_update runs from the vmstat work queue item by the workqueue kernel thread. If this code is running, it means there are at least two schedulable tasks: 1. The workqueue kernel thread, because it is running. 2. At least one more task, otherwise were were in idle and the workqueue kernel thread would not execute this work item. Unfortunately, having two schedulable tasks means we're not running tickless, so the check will never trigger - or have I've missed something obvious? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker gilad@benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/