From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCH V2 Resend 0/4] Create sched_select_cpu() and use it for workqueues and timers Date: Mon, 26 Nov 2012 09:03:58 -0800 Message-ID: <20121126170358.GE2474@linux.vnet.ibm.com> References: <1353948027.6276.38.camel@gandalf.local.home> Reply-To: paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: venki-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, Viresh Kumar , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, paul.mckenney-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, pdsw-power-team-5wv7dgnIgG8@public.gmane.org, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-rt-users-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Steven Rostedt Return-path: Content-Disposition: inline In-Reply-To: <1353948027.6276.38.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org Errors-To: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org List-Id: linux-rt-users.vger.kernel.org On Mon, Nov 26, 2012 at 11:40:27AM -0500, Steven Rostedt wrote: > On Mon, 2012-11-26 at 20:30 +0530, Viresh Kumar wrote: > > On 6 November 2012 16:08, Viresh Kumar wrote: > > > This is V2 Resend of my sched_select_cpu() work. Resend because didn't got much > > > attention on V2. Including more guys now in cc :) > > > > > > In order to save power, it would be useful to schedule work onto non-IDLE cpus > > > instead of waking up an IDLE one. > > > > > > To achieve this, we need scheduler to guide kernel frameworks (like: timers & > > > workqueues) on which is the most preferred CPU that must be used for these > > > tasks. > > > > > > This patchset is about implementing this concept. > > > > > > - The first patch adds sched_select_cpu() routine which returns the preferred > > > cpu which is non-idle. > > > - Second patch removes idle_cpu() calls from timer & hrtimer. > > > - Third patch is about adapting this change in workqueue framework. > > > - Fourth patch add migration capability in running timer > > > > > > Earlier discussions over v1 can be found here: > > > http://www.mail-archive.com/linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org/msg13342.html > > > > > > Earlier discussions over this concept were done at last LPC: > > > http://summit.linuxplumbersconf.org/lpc-2012/meeting/90/lpc2012-sched-timer-workqueue/ > > > > > > Module created for testing this behavior is present here: > > > http://git.linaro.org/gitweb?p=people/vireshk/module.git;a=summary > > > > Ping!! > > This is a really bad time of year to post new patches :-/ > A lot of people are trying to get their own work done by year end and > then there's holidays and such that are also distractions. Not to > mention that a new merge window will be opening soon. > > That said... > > As workqueues are set off by the CPU that queued it, what real benefit > does this give? A CPU was active when it queued the work and the work > should be done before it gets back to sleep. > > OK, an interrupt happens on an idle CPU and queues some work. That work > should execute before the CPU gets back to sleep, right? I fail to see > the benefit of trying to move that work elsewhere. The CPU had to wake > up to execute the interrupt. It's no longer in a deep sleep (or any > sleep for that matter). > > To me it seems best to avoid waking up an idle CPU in the first place. > > I'm still working off a turkey overdose, so maybe I'm missing something > obvious. If I understand correctly (though also suffering turkey OD), the idea is to offload work to more energy-efficient CPUs. Thanx, Paul