On 29 March 2013 23:10, Tejun Heo wrote:
> So the scheduler does know what it's doing after all, which is a nice
> news. Given the result, the best thing to do would be somehow marking
> these workqueues as unbound for powersaving?
Yes. I am going to do it soon.
--
To unsubscribe from this
On Fri, Mar 29, 2013 at 10:40:03AM -0700, Tejun Heo wrote:
> So the scheduler does know what it's doing after all, which is a nice
> news. Given the result, the best thing to do would be somehow marking
> these workqueues as unbound for powersaving?
BTW, recent changes to workqueue means that it
Hello, Viresh.
On Fri, Mar 29, 2013 at 12:57:23PM +0530, Viresh Kumar wrote:
> On 28 March 2013 23:43, Tejun Heo wrote:
> > Viresh, would it be difficult to make another measurement of the same
> > workload with the said workqueues converted to unbound? I think that
> > would at least provide a
On 28 March 2013 23:43, Tejun Heo wrote:
> Viresh, would it be difficult to make another measurement of the same
> workload with the said workqueues converted to unbound? I think that
> would at least provide a nice reference point.
My heart is shattered after getting the results :)
Cluster
On 28 March 2013 23:43, Tejun Heo t...@kernel.org wrote:
Viresh, would it be difficult to make another measurement of the same
workload with the said workqueues converted to unbound? I think that
would at least provide a nice reference point.
My heart is shattered after getting the results :)
Hello, Viresh.
On Fri, Mar 29, 2013 at 12:57:23PM +0530, Viresh Kumar wrote:
On 28 March 2013 23:43, Tejun Heo t...@kernel.org wrote:
Viresh, would it be difficult to make another measurement of the same
workload with the said workqueues converted to unbound? I think that
would at least
On Fri, Mar 29, 2013 at 10:40:03AM -0700, Tejun Heo wrote:
So the scheduler does know what it's doing after all, which is a nice
news. Given the result, the best thing to do would be somehow marking
these workqueues as unbound for powersaving?
BTW, recent changes to workqueue means that it
On 29 March 2013 23:10, Tejun Heo t...@kernel.org wrote:
So the scheduler does know what it's doing after all, which is a nice
news. Given the result, the best thing to do would be somehow marking
these workqueues as unbound for powersaving?
Yes. I am going to do it soon.
--
To unsubscribe
On 28 March 2013 23:43, Tejun Heo wrote:
> Ping. Peter, Ingo?
Thanks for your ping, even i was thinking of it since sometime :)
> Viresh, would it be difficult to make another measurement of the same
> workload with the said workqueues converted to unbound? I think that
> would at least
On Thu, Mar 21, 2013 at 11:29:37AM -0700, Tejun Heo wrote:
> Yes, I actually like that part a lot although I do wish the idle check
> was inlined.
>
> What I'm wondering is whether the kinda out-of-band decision via
> sched_select_cpu() is justified given that it can and is likely to go
> through
On Thu, Mar 21, 2013 at 11:29:37AM -0700, Tejun Heo wrote:
Yes, I actually like that part a lot although I do wish the idle check
was inlined.
What I'm wondering is whether the kinda out-of-band decision via
sched_select_cpu() is justified given that it can and is likely to go
through full
On 28 March 2013 23:43, Tejun Heo t...@kernel.org wrote:
Ping. Peter, Ingo?
Thanks for your ping, even i was thinking of it since sometime :)
Viresh, would it be difficult to make another measurement of the same
workload with the said workqueues converted to unbound? I think that
would at
Hey, Viresh.
On Thu, Mar 21, 2013 at 04:27:23PM +0530, Viresh Kumar wrote:
> > For some reason, I've been always unsure about this patchset. I've
> > been thinking about it past few days and I think I now know why.
>
> I knew this since the beginning and thought power numbers i showed might
>
On 21 March 2013 05:42, Tejun Heo wrote:
> On Mon, Mar 18, 2013 at 08:53:25PM +0530, Viresh Kumar wrote:
> For some reason, I've been always unsure about this patchset. I've
> been thinking about it past few days and I think I now know why.
I knew this since the beginning and thought power
On 21 March 2013 05:42, Tejun Heo t...@kernel.org wrote:
On Mon, Mar 18, 2013 at 08:53:25PM +0530, Viresh Kumar wrote:
For some reason, I've been always unsure about this patchset. I've
been thinking about it past few days and I think I now know why.
I knew this since the beginning and
Hey, Viresh.
On Thu, Mar 21, 2013 at 04:27:23PM +0530, Viresh Kumar wrote:
For some reason, I've been always unsure about this patchset. I've
been thinking about it past few days and I think I now know why.
I knew this since the beginning and thought power numbers i showed might
change
Hello, Viresh.
On Mon, Mar 18, 2013 at 08:53:25PM +0530, Viresh Kumar wrote:
> queue_work() queues work on current cpu. This may wake up an idle CPU, which
> is
> actually not required.
>
> Some of these works can be processed by any CPU and so we must select a
> non-idle
> CPU here. The
Hello, Viresh.
On Mon, Mar 18, 2013 at 08:53:25PM +0530, Viresh Kumar wrote:
queue_work() queues work on current cpu. This may wake up an idle CPU, which
is
actually not required.
Some of these works can be processed by any CPU and so we must select a
non-idle
CPU here. The initial idea
On 19 March 2013 10:45, Viresh Kumar wrote:
> On 18 March 2013 20:53, Viresh Kumar wrote:
>> queue_work() queues work on current cpu. This may wake up an idle CPU, which
>> is
>> actually not required.
>>
>> Some of these works can be processed by any CPU and so we must select a
>> non-idle
>>
On 19 March 2013 10:45, Viresh Kumar viresh.ku...@linaro.org wrote:
On 18 March 2013 20:53, Viresh Kumar viresh.ku...@linaro.org wrote:
queue_work() queues work on current cpu. This may wake up an idle CPU, which
is
actually not required.
Some of these works can be processed by any CPU and
On 18 March 2013 20:53, Viresh Kumar wrote:
> queue_work() queues work on current cpu. This may wake up an idle CPU, which
> is
> actually not required.
>
> Some of these works can be processed by any CPU and so we must select a
> non-idle
> CPU here. The initial idea was to modify
queue_work() queues work on current cpu. This may wake up an idle CPU, which is
actually not required.
Some of these works can be processed by any CPU and so we must select a non-idle
CPU here. The initial idea was to modify implementation of queue_work(), but
that may end up breaking lots of
queue_work() queues work on current cpu. This may wake up an idle CPU, which is
actually not required.
Some of these works can be processed by any CPU and so we must select a non-idle
CPU here. The initial idea was to modify implementation of queue_work(), but
that may end up breaking lots of
On 18 March 2013 20:53, Viresh Kumar viresh.ku...@linaro.org wrote:
queue_work() queues work on current cpu. This may wake up an idle CPU, which
is
actually not required.
Some of these works can be processed by any CPU and so we must select a
non-idle
CPU here. The initial idea was to
24 matches
Mail list logo
