On Fri, Jul 20, 2012 at 09:44:04PM +0200, Rafael J. Wysocki wrote:
> On Friday, July 20, 2012, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Jul 20, 2012 at 08:22:30PM +0200, Peter Zijlstra wrote:
> > > I really think people who use hotplug at high frequencies are on drugs
> > > and doing it wrong.
Rafael,
On Sat, Jul 21, 2012 at 1:14 AM, Rafael J. Wysocki wrote:
> On Friday, July 20, 2012, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Jul 20, 2012 at 08:22:30PM +0200, Peter Zijlstra wrote:
>> > I really think people who use hotplug at high frequencies are on drugs
>> > and doing it wrong.
>>
>>
Hello, Rafael.
On Fri, Jul 20, 2012 at 09:44:04PM +0200, Rafael J. Wysocki wrote:
> Well, there are use cases I'm not really familiar with.
>
> Pretty much the only use case I'm sufficiently familiar with is
> suspend/hibernate where we unplug all of the nonboot CPUs at one point.
>
> The other
On Friday, July 20, 2012, Tejun Heo wrote:
> Hello,
>
> On Fri, Jul 20, 2012 at 08:22:30PM +0200, Peter Zijlstra wrote:
> > I really think people who use hotplug at high frequencies are on drugs
> > and doing it wrong.
>
> I don't know. It does make some sense. It's not like we have any
> other
Hello,
On Fri, Jul 20, 2012 at 08:22:30PM +0200, Peter Zijlstra wrote:
> I really think people who use hotplug at high frequencies are on drugs
> and doing it wrong.
I don't know. It does make some sense. It's not like we have any
other mechanism to keep some processors completely quiesient, wh
On Fri, 2012-07-20 at 10:50 -0700, Tejun Heo wrote:
> Also, re-binding busy workers is easy. The idle ones are difficult
> and we have to do that anyway for PM optimization. What would be the
> benefit of not re-binding busy ones at the risk of continually
> transferring workers to another CPU gi
Hey, again.
On Fri, Jul 20, 2012 at 07:21:17PM +0200, Peter Zijlstra wrote:
> > So, the above was my rationale before this "we need to stop destroying
> > and re-creating kthreads across CPU hotplug events because phones do
> > it gazillion times". Now, I don't think we have any other way.
>
> O
Hey,
On Fri, Jul 20, 2012 at 07:19:27PM +0200, Peter Zijlstra wrote:
> > Hmmm? Not really. We need to keep count of the ones which reqested
> > fixed binding - ie. the ones which explicitly used queue_work_on() -
> > and then flush on wq CPU_DOWN. Then, we need to audit the current
> > users wh
On Fri, 2012-07-20 at 10:02 -0700, Tejun Heo wrote:
> Hey, Peter.
>
> On Fri, Jul 20, 2012 at 05:48:31PM +0200, Peter Zijlstra wrote:
> > On Tue, 2012-07-17 at 10:12 -0700, Tejun Heo wrote:
> > > While this makes rebinding somewhat more complicated, as it has to be
> > > able to rebind idle worker
On Fri, 2012-07-20 at 10:08 -0700, Tejun Heo wrote:
> Hello, Peter.
>
> On Fri, Jul 20, 2012 at 07:01:40PM +0200, Peter Zijlstra wrote:
> > On Fri, 2012-07-20 at 09:52 -0700, Tejun Heo wrote:
> > > Ooh, yeah, I agree. That's next on the wq to-do list. The problem is
> > > that queue_work() is im
Hello, Peter.
On Fri, Jul 20, 2012 at 07:01:40PM +0200, Peter Zijlstra wrote:
> On Fri, 2012-07-20 at 09:52 -0700, Tejun Heo wrote:
> > Ooh, yeah, I agree. That's next on the wq to-do list. The problem is
> > that queue_work() is implemented in terms of queue_work_on().
>
> But that's trivial
Hey, Peter.
On Fri, Jul 20, 2012 at 05:48:31PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-07-17 at 10:12 -0700, Tejun Heo wrote:
> > While this makes rebinding somewhat more complicated, as it has to be
> > able to rebind idle workers too, it allows overall hotplug path to be
> > much simpler.
On Fri, 2012-07-20 at 09:52 -0700, Tejun Heo wrote:
> Ooh, yeah, I agree. That's next on the wq to-do list. The problem is
> that queue_work() is implemented in terms of queue_work_on().
But that's trivial to fix, both could use __queue_work() without too
much bother, right?
> In most
> cases
Hello, Peter.
On Fri, Jul 20, 2012 at 06:39:51PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-07-17 at 10:12 -0700, Tejun Heo wrote:
> > Currently, workqueue destroys all workers for offline CPUs unless
> > there are lingering work items.
>
> _that_ is the root of all ugly in that thing. I still
On Tue, 2012-07-17 at 10:12 -0700, Tejun Heo wrote:
> Currently, workqueue destroys all workers for offline CPUs unless
> there are lingering work items.
_that_ is the root of all ugly in that thing. I still find it utterly
insane you can create 'per-cpu' workqueues and then violate the per-cpu
p
On Tue, 2012-07-17 at 10:12 -0700, Tejun Heo wrote:
> While this makes rebinding somewhat more complicated, as it has to be
> able to rebind idle workers too, it allows overall hotplug path to be
> much simpler.
I really don't see the point of re-binding.. at that point you've well
and proper vi
Hello,
On Tue, Jul 17, 2012 at 08:43:42PM +0200, Rafael J. Wysocki wrote:
> I suppose you're going to push them through your tree, right? I that case
> please free to add my Acked-by to them.
Yeah, I'm planning to push these through workqueue tree once 3.6 merge
window opens. Acked-bys added.
On Tuesday, July 17, 2012, Tejun Heo wrote:
> Currently, workqueue destroys all workers for offline CPUs unless
> there are lingering work items. On some platforms, CPU hotplugs are
> used as part of runtime powersaving and thus can be very frequent.
> The overhead of destroying and re-creating wo
Currently, workqueue destroys all workers for offline CPUs unless
there are lingering work items. On some platforms, CPU hotplugs are
used as part of runtime powersaving and thus can be very frequent.
The overhead of destroying and re-creating workers on each cycle can
be noticeable.
In addition,
19 matches
Mail list logo
