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 list:
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 A1
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 provid
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
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
> ch
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 numb
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 initia
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 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 implementatio
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 kern
12 matches
Mail list logo