On 10 January 2013 00:19, Tejun Heo wrote:
> On Mon, Jan 07, 2013 at 11:37:22PM +0530, Viresh Kumar wrote:
>> We are talking about a core being idle from schedulers perspective :)
>
> But it's not like cpu doesn't consume power if scheduler considers it
> idle, right? Can you please explain in
Hello,
On Mon, Jan 07, 2013 at 11:37:22PM +0530, Viresh Kumar wrote:
> On 7 January 2013 20:34, Tejun Heo wrote:
> > The latter part "not using idle cpu just for processing work" does
> > apply to homogeneous systems too but as I wrote earlier work items
> > don't spontaneously happen on an idle
Hello,
On Mon, Jan 07, 2013 at 11:37:22PM +0530, Viresh Kumar wrote:
On 7 January 2013 20:34, Tejun Heo t...@kernel.org wrote:
The latter part not using idle cpu just for processing work does
apply to homogeneous systems too but as I wrote earlier work items
don't spontaneously happen on
On 10 January 2013 00:19, Tejun Heo t...@kernel.org wrote:
On Mon, Jan 07, 2013 at 11:37:22PM +0530, Viresh Kumar wrote:
We are talking about a core being idle from schedulers perspective :)
But it's not like cpu doesn't consume power if scheduler considers it
idle, right? Can you please
Hi Steven,
On 8 January 2013 03:59, Steven Rostedt wrote:
> On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
>
>> > By default, I would suggest for cache locality,
>> > that we try to keep it on the same CPU. But if there's a better CPU to
>> > run on, it runs there.
>>
>> That would break
On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
> > By default, I would suggest for cache locality,
> > that we try to keep it on the same CPU. But if there's a better CPU to
> > run on, it runs there.
>
> That would break our intention behind this routine. We should run
> it on a cpu
[Removed Suresh and Venki from discussion, they switched their companies
probably]
On 7 January 2013 20:34, Tejun Heo wrote:
> The latter part "not using idle cpu just for processing work" does
> apply to homogeneous systems too but as I wrote earlier work items
> don't spontaneously happen on
On 7 January 2013 18:58, Steven Rostedt wrote:
> On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
>> I have another idea that we can try:
>>
>> queue_work_on_any_cpu().
>
> I think this is a good idea.
:) :)
>> - the mask of cpus to schedule this work on
>> OR
>> - Sched Level
On Mon, Jan 7, 2013 at 8:34 PM, Tejun Heo wrote:
> Hello, Viresh.
>
> On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
>> Firstly the root cause of this patchset.
>>
>> Myself and some others in Linaro are working on ARM future cores:
>> big.LITTLE systems.
>> Here we have few very
Hello, Viresh.
On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
> Firstly the root cause of this patchset.
>
> Myself and some others in Linaro are working on ARM future cores:
> big.LITTLE systems.
> Here we have few very powerful, high power consuming cores (big,
> currently
On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
> Hi Tejun,
>
> On 4 January 2013 20:39, Tejun Heo wrote:
> > I don't know either. Changing behavior subtly like this is hard. I
> > usually try to spot some problem cases and try to identify patterns
> > there. Once you identify a few of
Hi Tejun,
On 4 January 2013 20:39, Tejun Heo wrote:
> I don't know either. Changing behavior subtly like this is hard. I
> usually try to spot some problem cases and try to identify patterns
> there. Once you identify a few of them, understanding and detecting
> other problem cases get a lot
Hi Tejun,
On 4 January 2013 20:39, Tejun Heo t...@kernel.org wrote:
I don't know either. Changing behavior subtly like this is hard. I
usually try to spot some problem cases and try to identify patterns
there. Once you identify a few of them, understanding and detecting
other problem cases
On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
Hi Tejun,
On 4 January 2013 20:39, Tejun Heo t...@kernel.org wrote:
I don't know either. Changing behavior subtly like this is hard. I
usually try to spot some problem cases and try to identify patterns
there. Once you identify a
Hello, Viresh.
On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
Firstly the root cause of this patchset.
Myself and some others in Linaro are working on ARM future cores:
big.LITTLE systems.
Here we have few very powerful, high power consuming cores (big,
currently A15's) and
On Mon, Jan 7, 2013 at 8:34 PM, Tejun Heo t...@kernel.org wrote:
Hello, Viresh.
On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
Firstly the root cause of this patchset.
Myself and some others in Linaro are working on ARM future cores:
big.LITTLE systems.
Here we have few very
On 7 January 2013 18:58, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
I have another idea that we can try:
queue_work_on_any_cpu().
I think this is a good idea.
:) :)
- the mask of cpus to schedule this work on
OR
- Sched Level
[Removed Suresh and Venki from discussion, they switched their companies
probably]
On 7 January 2013 20:34, Tejun Heo t...@kernel.org wrote:
The latter part not using idle cpu just for processing work does
apply to homogeneous systems too but as I wrote earlier work items
don't spontaneously
On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
By default, I would suggest for cache locality,
that we try to keep it on the same CPU. But if there's a better CPU to
run on, it runs there.
That would break our intention behind this routine. We should run
it on a cpu which we
Hi Steven,
On 8 January 2013 03:59, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
By default, I would suggest for cache locality,
that we try to keep it on the same CPU. But if there's a better CPU to
run on, it runs there.
That would
Hello, Viresh.
On Fri, Jan 04, 2013 at 04:41:47PM +0530, Viresh Kumar wrote:
> I got a list of files where cpu/processor_id strings are found, which
> may break with
> this patch (still can't guarantee as i don't have knowledge of these
> drivers)...
...
> I am not sure what to do now :) , can
Hi Tejun,
On 27 November 2012 10:49, Viresh Kumar wrote:
> On 26 November 2012 22:45, Tejun Heo wrote:
>> On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
>
>> I'm pretty skeptical about this. queue_work() w/o explicit CPU
>> assignment has always guaranteed that the work item
Hi Tejun,
On 27 November 2012 10:49, Viresh Kumar viresh.ku...@linaro.org wrote:
On 26 November 2012 22:45, Tejun Heo t...@kernel.org wrote:
On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
I'm pretty skeptical about this. queue_work() w/o explicit CPU
assignment has always
Hello, Viresh.
On Fri, Jan 04, 2013 at 04:41:47PM +0530, Viresh Kumar wrote:
I got a list of files where cpu/processor_id strings are found, which
may break with
this patch (still can't guarantee as i don't have knowledge of these
drivers)...
...
I am not sure what to do now :) , can you
On 27 November 2012 16:04, Steven Rostedt wrote:
> On Tue, 2012-11-27 at 15:55 +0100, Vincent Guittot wrote:
>> On 27 November 2012 14:59, Steven Rostedt wrote:
>> > On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
>> >> On 27 November 2012 18:56, Steven Rostedt wrote:
>> >> > A couple of
On Tue, 2012-11-27 at 15:55 +0100, Vincent Guittot wrote:
> On 27 November 2012 14:59, Steven Rostedt wrote:
> > On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
> >> On 27 November 2012 18:56, Steven Rostedt wrote:
> >> > A couple of things. The sched_select_cpu() is not cheap. It has a
On 27 November 2012 14:59, Steven Rostedt wrote:
> On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
>> On 27 November 2012 18:56, Steven Rostedt wrote:
>> > A couple of things. The sched_select_cpu() is not cheap. It has a double
>> > loop of domains/cpus looking for a non idle cpu. If we
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
> On 27 November 2012 18:56, Steven Rostedt wrote:
> > A couple of things. The sched_select_cpu() is not cheap. It has a double
> > loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
> > and we are CPU 1023 and all other
On 27 November 2012 18:56, Steven Rostedt wrote:
> A couple of things. The sched_select_cpu() is not cheap. It has a double
> loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
> and we are CPU 1023 and all other CPUs happen to be idle, we could be
> searching 1023 CPUs before
On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
> 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.
On 27 November 2012 06:19, Viresh Kumar wrote:
> Hi Tejun,
>
> On 26 November 2012 22:45, Tejun Heo wrote:
>> On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
>
>> I'm pretty skeptical about this. queue_work() w/o explicit CPU
>> assignment has always guaranteed that the work item
On 27 November 2012 06:19, Viresh Kumar viresh.ku...@linaro.org wrote:
Hi Tejun,
On 26 November 2012 22:45, Tejun Heo t...@kernel.org wrote:
On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
I'm pretty skeptical about this. queue_work() w/o explicit CPU
assignment has always
On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
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
On 27 November 2012 18:56, Steven Rostedt rost...@goodmis.org wrote:
A couple of things. The sched_select_cpu() is not cheap. It has a double
loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
and we are CPU 1023 and all other CPUs happen to be idle, we could be
searching
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
On 27 November 2012 18:56, Steven Rostedt rost...@goodmis.org wrote:
A couple of things. The sched_select_cpu() is not cheap. It has a double
loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
and we are CPU 1023 and
On 27 November 2012 14:59, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
On 27 November 2012 18:56, Steven Rostedt rost...@goodmis.org wrote:
A couple of things. The sched_select_cpu() is not cheap. It has a double
loop of domains/cpus
On Tue, 2012-11-27 at 15:55 +0100, Vincent Guittot wrote:
On 27 November 2012 14:59, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
On 27 November 2012 18:56, Steven Rostedt rost...@goodmis.org wrote:
A couple of things. The
On 27 November 2012 16:04, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2012-11-27 at 15:55 +0100, Vincent Guittot wrote:
On 27 November 2012 14:59, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
On 27 November 2012 18:56, Steven Rostedt
Hi Tejun,
On 26 November 2012 22:45, Tejun Heo wrote:
> On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
> I'm pretty skeptical about this. queue_work() w/o explicit CPU
> assignment has always guaranteed that the work item will be executed
> on the same CPU. I don't think there
Hello, Viresh.
On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
> 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
Hello, Viresh.
On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
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
Hi Tejun,
On 26 November 2012 22:45, Tejun Heo t...@kernel.org wrote:
On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
I'm pretty skeptical about this. queue_work() w/o explicit CPU
assignment has always guaranteed that the work item will be executed
on the same CPU. I don't
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
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
44 matches
Mail list logo
