On 24 Sep 2012, at 12:03, Alexander Sack wrote:
> On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott wrote:
>> Unfortunately, not as easy as it sounds. We'd have to actually change the
>> dispatcher to intercept submissions to vexpress, and then re-route them to
>> vexpress-a9, because we can'\t have
On 25 September 2012 10:22, Dave Pigott wrote:
> On 24 Sep 2012, at 12:03, Alexander Sack wrote:
>
>> On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott wrote:
>>> Unfortunately, not as easy as it sounds. We'd have to actually change the
>>> dispatcher to intercept submissions to vexpress, and then re
On 25 Sep 2012, at 08:40, Fathi Boudra wrote:
> On 25 September 2012 10:22, Dave Pigott wrote:
>> On 24 Sep 2012, at 12:03, Alexander Sack wrote:
>>
>>> On Mon, Sep 24, 2012 at 12:48 PM, Dave Pigott
>>> wrote:
Unfortunately, not as easy as it sounds. We'd have to actually change the
flush_delayed_work() and flush_delayed_work_sync() had major portion of code
similar. This patch introduces another routine __flush_delayed_work() which
contains the common part to avoid code duplication.
Signed-off-by: Viresh Kumar
---
kernel/workqueue.c | 15 +--
1 file changed, 9
Workqueues queues work on current cpu, if the caller haven't passed a preferred
cpu. This may wake up an idle CPU, which is actually not required.
This work can be processed by any CPU and so we must select a non-idle CPU here.
This patch adds in support in workqueue framework to get preferred CPU
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 i
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 routine returns the
On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
> +/* sched-domain levels */
> +#define SD_SIBLING 0x01/* Only for CONFIG_SCHED_SMT */
> +#define SD_MC 0x02/* Only for CONFIG_SCHED_MC */
> +#define SD_BOOK0x04/* Only for CONFIG
On 25 September 2012 16:06, Viresh Kumar wrote:
> Test case 2:
> ---
> I have created a small module, which does following:
> - Create one work for each CPU (using queue_work_on(), so must schedule on
> that
> cpu)
> - Above work, will queue "n" works for each cpu with queue_work(). The
On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
> @@ -1066,8 +1076,9 @@ int queue_work(struct workqueue_struct *wq,
> struct work_struct *work)
> {
> int ret;
>
> - ret = queue_work_on(get_cpu(), wq, work);
> - put_cpu();
> + preempt_disable();
> + ret = qu
On 25 September 2012 16:52, Peter Zijlstra wrote:
> On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
>> @@ -1066,8 +1076,9 @@ int queue_work(struct workqueue_struct *wq,
>> struct work_struct *work)
>> {
>> int ret;
>>
>> - ret = queue_work_on(get_cpu(), wq, work);
>> -
On 25 September 2012 13:30, Viresh Kumar wrote:
> On 25 September 2012 16:52, Peter Zijlstra wrote:
>> On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
>>> @@ -1066,8 +1076,9 @@ int queue_work(struct workqueue_struct *wq,
>>> struct work_struct *work)
>>> {
>>> int ret;
>>>
>>> -
On Tue, 2012-09-25 at 17:00 +0530, Viresh Kumar wrote:
> But this is what the initial idea during LPC we had.
Yeah.. that's true.
> Any improvements here you can suggest?
We could uhm... /me tries thinking ... reuse some of the NOHZ magic?
Would that be sufficient, not waking a NOHZ cpu, or do
On Tue, 2012-09-25 at 13:40 +0200, Peter Zijlstra wrote:
> On Tue, 2012-09-25 at 17:00 +0530, Viresh Kumar wrote:
> > But this is what the initial idea during LPC we had.
>
> Yeah.. that's true.
>
> > Any improvements here you can suggest?
>
> We could uhm... /me tries thinking ... reuse some
synchronize_rcu blocks the caller of opp_enable/disbale
for a complete grace period. This blocking duration prevents
any intensive use of the functions. Replace synchronize_rcu
by call_rcu which will call our function for freeing the old
opp element.
The duration of opp_enable and opp_disable will
On 09/24/2012 10:34 PM, Rajagopal Venkat wrote:
On 24 September 2012 21:27, Chris Ferron wrote:
On 09/24/2012 06:28 AM, Rajagopal Venkat wrote:
This patch adds following minor changes to prepare powertop
to support Android platform.
- Add missing HAVE_CONFIG_H conditional check.
- remove un-u
https://wiki.linaro.org/projects/big.LITTLE.MP
Announcement
==
== big.LITTLE Mini-Summit @ Linaro Connect Copenhagen Q32012 ==
Thursday November 1, 2012
Plenaries: 8.30 - 9.00, 2 x 15 minutes
9am - 1pm:
1 break 10.45am to 11.00am
Plenaries
- Introduction to th
On Tue, Sep 25, 2012 at 04:06:07PM +0530, Viresh Kumar wrote:
> flush_delayed_work() and flush_delayed_work_sync() had major portion of code
> similar. This patch introduces another routine __flush_delayed_work() which
> contains the common part to avoid code duplication.
This part has seen a lot
Hello,
On Tue, Sep 25, 2012 at 04:06:08PM +0530, Viresh Kumar wrote:
> +config MIGRATE_WQ
> + bool "(EXPERIMENTAL) Migrate Workqueues to non-idle cpu"
> + depends on SMP && EXPERIMENTAL
> + help
> + Workqueues queues work on current cpu, if the caller haven't passed a
> + p
Please take a look at:
https://wiki.linaro.org/Platform/Android/Meetings/2012-09-26
Feel free to add to the agenda and join us in #linaro-meeting on
irc.freenode.net at 13:00 UTC on 2012/9/26.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software fo
On 25 September 2012 23:17, Tejun Heo wrote:
> On Tue, Sep 25, 2012 at 04:06:07PM +0530, Viresh Kumar wrote:
>> flush_delayed_work() and flush_delayed_work_sync() had major portion of code
>> similar. This patch introduces another routine __flush_delayed_work() which
>> contains the common part to
21 matches
Mail list logo