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]
Message-ID: <1353948027.6276.38.camel@gandalf.local.home>
Date:	Mon, 26 Nov 2012 11:40:27 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	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, 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.

-- Steve


--
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