From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752355AbbC0OT1 (ORCPT ); Fri, 27 Mar 2015 10:19:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34089 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751025AbbC0OTZ (ORCPT ); Fri, 27 Mar 2015 10:19:25 -0400 Date: Fri, 27 Mar 2015 15:19:22 +0100 From: Michal Hocko To: Viresh Kumar Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, cl@linux.com, linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org, vinmenon@codeaurora.org, shashim@codeaurora.org, mgorman@suse.de, dave@stgolabs.net, koct9i@gmail.com, linux-mm@kvack.org Subject: Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work Message-ID: <20150327141922.GC5481@dhcp22.suse.cz> References: <359c926bc85cdf79650e39f2344c2083002545bb.1427347966.git.viresh.kumar@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <359c926bc85cdf79650e39f2344c2083002545bb.1427347966.git.viresh.kumar@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 26-03-15 11:09:01, Viresh Kumar wrote: > A delayed work to schedule vmstat_shepherd() is queued at periodic intervals for > internal working of vmstat core. This work and its timer end up waking an idle > cpu sometimes, as this always stays on CPU0. > > Because we re-queue the work from its handler, idle_cpu() returns false and so > the timer (used by delayed work) never migrates to any other CPU. > > This may not be the desired behavior always as waking up an idle CPU to queue > work on few other CPUs isn't good from power-consumption point of view. Wouldn't something like I was suggesting few months back (http://article.gmane.org/gmane.linux.kernel.mm/127569) solve this problem as well? Scheduler should be idle aware, no? I mean it shouldn't wake up an idle CPU if the task might run on another one. -- Michal Hocko SUSE Labs