lkml.org 
[lkml]   [2012]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH V2 Resend 0/4] Create sched_select_cpu() and use it for workqueues and timers
From
Date
On Mon, 2012-11-26 at 20:30 +0530, Viresh Kumar wrote:
> On 6 November 2012 16:08, Viresh Kumar <viresh.kumar@linaro.org> 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@lists.linaro.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.

-- Steve




\
 
 \ /
  Last update: 2012-11-26 18:01    [W:0.228 / U:0.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site