lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Nov 2012 09:03:58 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>, pjt@...gle.com,
	paul.mckenney@...aro.org, tglx@...utronix.de, tj@...nel.org,
	suresh.b.siddha@...el.com, venki@...gle.com, mingo@...hat.com,
	peterz@...radead.org, Arvind.Chauhan@....com,
	linaro-dev@...ts.linaro.org, patches@...aro.org,
	pdsw-power-team@....com, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org
Subject: Re: [PATCH V2 Resend 0/4] Create sched_select_cpu() and use it for
 workqueues and timers

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 <viresh.kumar@...aro.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.

If I understand correctly (though also suffering turkey OD), the idea is
to offload work to more energy-efficient CPUs.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ