OnDemand governor vs. work queue

OnDemand governor vs. work queue

[Benjamin Herrenschmidt]

Hi !

From what I've seen, the OnDemand governor works using a timer/workqueue
pair.

That annoys me a bit as the setup I have on PowerMacs can take several
ms to transition (due to voltage transition mostly). I don't like the
idea of hogging keventd that long.

Wouldn't it make sense, especially for setups where transition latency
is high (by high, I mean significant compared to HZ for example), to
actually spawn a kthread and do the sampling & switching from there ?

Regard,
Ben.

Re: OnDemand governor vs. work queue

[Bruno Ducrot]

On Wed, May 25, 2005 at 01:26:40PM +1000, Benjamin Herrenschmidt wrote:
> Hi !
> 
> >From what I've seen, the OnDemand governor works using a timer/workqueue
> pair.
> 
> That annoys me a bit as the setup I have on PowerMacs can take several
> ms to transition (due to voltage transition mostly). I don't like the
> idea of hogging keventd that long.
> 
> Wouldn't it make sense, especially for setups where transition latency
> is high (by high, I mean significant compared to HZ for example), to
> actually spawn a kthread and do the sampling & switching from there ?

I'm wondering if in that case a userspace daemon will be more suited..

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: OnDemand governor vs. work queue

[Benjamin Herrenschmidt]

On Wed, 2005-05-25 at 11:59 +0200, Bruno Ducrot wrote:
> On Wed, May 25, 2005 at 01:26:40PM +1000, Benjamin Herrenschmidt wrote:
> > Hi !
> > 
> > >From what I've seen, the OnDemand governor works using a timer/workqueue
> > pair.
> > 
> > That annoys me a bit as the setup I have on PowerMacs can take several
> > ms to transition (due to voltage transition mostly). I don't like the
> > idea of hogging keventd that long.
> > 
> > Wouldn't it make sense, especially for setups where transition latency
> > is high (by high, I mean significant compared to HZ for example), to
> > actually spawn a kthread and do the sampling & switching from there ?
> 
> I'm wondering if in that case a userspace daemon will be more suited..

This is what I do & recommend for powerbook users (so far, powernowd
works like a charm), but since OnDemand governor advertises working with
latencies as big as 10ms, I was wondering ...

Ben.

RE: OnDemand governor vs. work queue

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>Benjamin Herrenschmidt
>Sent: Wednesday, May 25, 2005 2:27 PM
>To: Bruno Ducrot
>Cc: cpufreq@lists.linux.org.uk
>Subject: Re: OnDemand governor vs. work queue
>
>On Wed, 2005-05-25 at 11:59 +0200, Bruno Ducrot wrote:
>> On Wed, May 25, 2005 at 01:26:40PM +1000, Benjamin 
>Herrenschmidt wrote:
>> > Hi !
>> > 
>> > >From what I've seen, the OnDemand governor works using a 
>timer/workqueue
>> > pair.
>> > 
>> > That annoys me a bit as the setup I have on PowerMacs can 
>take several
>> > ms to transition (due to voltage transition mostly). I 
>don't like the
>> > idea of hogging keventd that long.
>> > 
>> > Wouldn't it make sense, especially for setups where 
>transition latency
>> > is high (by high, I mean significant compared to HZ for 
>example), to
>> > actually spawn a kthread and do the sampling & switching 
>from there ?
>> 
>> I'm wondering if in that case a userspace daemon will be 
>more suited..
>
>This is what I do & recommend for powerbook users (so far, powernowd
>works like a charm), but since OnDemand governor advertises 
>working with
>latencies as big as 10ms, I was wondering ...
>
>Ben.
>

Agreed. For the larger latency transitions, ondemand governor should 
use its own thread rather than keventd. Probably, it may make sense to 
have separate threads for each CPU as well in that case (as otherwise 
this thread will end up being moved around from one CPU to other. I will

look at this in a couple of weeks unless someone beats me to it and 
sends the patch before that :).

Thanks,
Venki

RE: OnDemand governor vs. work queue

[Benjamin Herrenschmidt]

> Agreed. For the larger latency transitions, ondemand governor should 
> use its own thread rather than keventd. Probably, it may make sense to 
> have separate threads for each CPU as well in that case (as otherwise 
> this thread will end up being moved around from one CPU to other. I will
> 
> look at this in a couple of weeks unless someone beats me to it and 
> sends the patch before that :).

A per-CPU thread could be a custom work queue (easy to implement form
current code) but also a resource waste. I don't think there is that
much of a problem having that thread moved around.

Ben.

Re: OnDemand governor vs. work queue

[Venkatesh Pallipadi]

On Thu, May 26, 2005 at 07:48:27AM +1000, Benjamin Herrenschmidt wrote:
> 
> > Agreed. For the larger latency transitions, ondemand governor should 
> > use its own thread rather than keventd. Probably, it may make sense to 
> > have separate threads for each CPU as well in that case (as otherwise 
> > this thread will end up being moved around from one CPU to other. I will
> > 
> > look at this in a couple of weeks unless someone beats me to it and 
> > sends the patch before that :).
> 
> A per-CPU thread could be a custom work queue (easy to implement form
> current code) but also a resource waste. I don't think there is that
> much of a problem having that thread moved around.
> 

This is how things work today.
- ondemand (keventd) wakes up on some CPU A.
- Then we loop through all the CPU Is
	- Figure out whether we need to increase the frequency
		- If yes, the underlying governor may (on i386, x86-64 it will)
		  move the thread to CPU I
		- Change the frequency
		- Move the thread back to CPU A.


And each of this affinity calls will wakeup migration thread to do the proper 
affinity and also IPIs for resched. At this moment I am not sure how much 
overhead we have due to this affinity. I need to look closely whether this 
is overhead is significant (Especially on systems with 4 or more CPUs).

-Thanks,
Venki