Dynamic frequency governor

Dynamic frequency governor

[Moore, Robert]

Hi all,

I've been chartered to implement a multi-state algorithm for Linux;
this will be a new governor that adjusts the CPU frequency based upon
percent CPU utilization as reported from the kernel idle handler.

Has any work been done (or is being done) in this area?  I don't want to
rewrite the wheel.

Thanks,
Bob Moore
Intel Corporation

Re: Dynamic frequency governor

[Jeremy Fitzhardinge]

On Fri, 2003-10-17 at 14:14, Moore, Robert wrote:
> Hi all,
> 
> I've been chartered to implement a multi-state algorithm for Linux;
> this will be a new governor that adjusts the CPU frequency based upon
> percent CPU utilization as reported from the kernel idle handler.
> 
> Has any work been done (or is being done) in this area?  I don't want to
> rewrite the wheel.

Speedfreq (http://www.goop.org/~jeremy/speedfreq) does this in
userspace.  I'm not sure there's much win in putting it into the kernel,
but a better idle measurement would be nice (I use /proc/uptime, which
can only be reliably polled a couple of times a second).

	J

Re: Dynamic frequency governor

[Vivek Haldar]

Jeremy Fitzhardinge wrote:

>On Fri, 2003-10-17 at 14:14, Moore, Robert wrote:
>  
>
>>Hi all,
>>
>>I've been chartered to implement a multi-state algorithm for Linux;
>>this will be a new governor that adjusts the CPU frequency based upon
>>percent CPU utilization as reported from the kernel idle handler.
>>
>>Has any work been done (or is being done) in this area?  I don't want to
>>rewrite the wheel.
>>    
>>
>
>Speedfreq (http://www.goop.org/~jeremy/speedfreq) does this in
>userspace.  I'm not sure there's much win in putting it into the kernel,
>but a better idle measurement would be nice (I use /proc/uptime, which
>can only be reliably polled a couple of times a second).
>
I have a very similar tool called LAMP - 
http://gandalf.ics.uci.edu/~haldar/lamp/ . I didn't know about your 
program until this post.

I agree with you that this should be in user-space, not in kernel space.

Vivek.

Re: Dynamic frequency governor

[Jeroen van der Vegt]

And I just wrote a first public version of yet another similar tool,
Slowmotion: http://atlas.et.tudelft.nl/ajvdvegt/laptop/slowmotion.tgz

It only uses speeds available on your platform. It the algorithm tries
to match CPU-speed to CPU-load: at 0% load, it'll go to lowest speed, at
full load to highest speed. At e.g. 50% cpu-load, it'll go to the speed
right in the middle between min. speed and max. speed.
It hasn't really surpassed the 'works for me' phase though. ;)

I didn't know about the other two programs mentioned either :(

Jeroen.

Op za 18-10-2003, om 07:58 schreef Vivek Haldar:
> Jeremy Fitzhardinge wrote:
> 
> >On Fri, 2003-10-17 at 14:14, Moore, Robert wrote:
> >  
> >
> >>Hi all,
> >>
> >>I've been chartered to implement a multi-state algorithm for Linux;
> >>this will be a new governor that adjusts the CPU frequency based upon
> >>percent CPU utilization as reported from the kernel idle handler.
> >>
> >>Has any work been done (or is being done) in this area?  I don't want to
> >>rewrite the wheel.
> >>    
> >>
> >
> >Speedfreq (http://www.goop.org/~jeremy/speedfreq) does this in
> >userspace.  I'm not sure there's much win in putting it into the kernel,
> >but a better idle measurement would be nice (I use /proc/uptime, which
> >can only be reliably polled a couple of times a second).
> >
> I have a very similar tool called LAMP - 
> http://gandalf.ics.uci.edu/~haldar/lamp/ . I didn't know about your 
> program until this post.
> 
> I agree with you that this should be in user-space, not in kernel space.
> 
> Vivek.
> 

Re: Dynamic frequency governor

[David Kar-Fai Tam]

On Fri, 17 Oct 2003, Moore, Robert wrote:

> I've been chartered to implement a multi-state algorithm for Linux;
> this will be a new governor that adjusts the CPU frequency based upon
> percent CPU utilization as reported from the kernel idle handler.
> 
> Has any work been done (or is being done) in this area?  I don't want to
> rewrite the wheel.

I am a graduate student working on a course project involving
implementing DVS algorithms on mobile devices.

We (3 graduate students) are attempting to implement several DVS
algorithms (as described in various research papers) in Linux 2.6 using
the CPUFreq API. According to Dominik Brodowski, we will be attempting to 
implement a dynamic governor for the CPUFreq API.
We plan to do this in the kernel.

You can check out our project website at
http://www.eecg.toronto.edu/~tamda/csc2228/
You will find a proposal and a recent progress report.

--
David Tam
tamda@eecg.toronto.edu

Re: Dynamic frequency governor

[David Kar-Fai Tam]

On Sat, 18 Oct 2003, David Kar-Fai Tam wrote:
> I am a graduate student working on a course project involving
> implementing DVS algorithms on mobile devices.
> 
> We (3 graduate students) are attempting to implement several DVS
> algorithms (as described in various research papers) in Linux 2.6 using
> the CPUFreq API. According to Dominik Brodowski, we will be attempting to 
> implement a dynamic governor for the CPUFreq API.
> We plan to do this in the kernel.
> 
> You can check out our project website at
> http://www.eecg.toronto.edu/~tamda/csc2228/
> You will find a proposal and a recent progress report.

Status update:
We have finished our DVS project.
If interested, please check out the above website.
There is a final report, presentation slides describing our
accomplishments, and source code.

We have implemented the AVGn, past, peak, and our own "future" DVS 
algorithms on kernel 2.6.0-test9.

Thanks.

--
David Tam
tamda@eecg.toronto.edu

Re: Dynamic frequency governor

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 4246 bytes --]

On Mon, Dec 22, 2003 at 04:41:40PM -0500, David Kar-Fai Tam wrote:
> On Sat, 18 Oct 2003, David Kar-Fai Tam wrote:
> > I am a graduate student working on a course project involving
> > implementing DVS algorithms on mobile devices.
> > 
> > We (3 graduate students) are attempting to implement several DVS
> > algorithms (as described in various research papers) in Linux 2.6 using
> > the CPUFreq API. According to Dominik Brodowski, we will be attempting to 
> > implement a dynamic governor for the CPUFreq API.
> > We plan to do this in the kernel.
> > 
> > You can check out our project website at
> > http://www.eecg.toronto.edu/~tamda/csc2228/
> > You will find a proposal and a recent progress report.
> 
> Status update:
> We have finished our DVS project.
> If interested, please check out the above website.
> There is a final report, presentation slides describing our
> accomplishments, and source code.
> 
> We have implemented the AVGn, past, peak, and our own "future" DVS 
> algorithms on kernel 2.6.0-test9.

First of all, many thanks and congratulations for this tremendous
accomplishment.

However -- as with (almost) all open source projects -- there is still much
room for improvements in your source code, some of which I'll adress below.
I hope you're willing to continue maintaining your CPUfreq governor(s) until
they are (possibly) merged into the Linux kernel and beyond.


1.) Source code format

The source code available on your project homepage is in a somewhat unusual
form for additions to the Linux kernel -- a compressed archive of some
files. Usually, such additions are made available in "diff" form -- for
example,

cd drivers/cpufreq/
cp cpufreq.c cpufreq.c.original
diff -up cpufreq.c.original cpufreq.c > ../../../cpufreq-2.6.3-rc2-fix-memory-leak

For details, check out Documentation/SubmittingPatches in the linux kernel
sources.

These "diffs" are easier to discuss and to apply to other kernels
(patch(1)).

Also, if you modify existing files, it's best to do this in a seperate
patch/diff. Also, if such a change is big or invasive, it's good to split it
up into several, logical pieces.


2.) structure or cpufreq_dvs.c

You have implemented four different scaling algorithms. It's good that
you put them into one file -- cpufreq_dvs.c -- as they share at least some
code. However, the sperate selection method (file dvs_algorithm) is
unnecessary and, in my opinion, bad. Each algorithm can and should be an
independent cpufreq governor, and have its independent cpufreq_governor
struct.


3.) content of cpufreq_dvs.c

I'll focus on cpufreq_dvs.c now, as I don't have the necessary insight into
the kernel scheduler to comment on these parts.

  // INCREASE means increase the speed by a number of steps
  // DECREASE is similar
  // SETSPEED means set a certain speed

SETSPEED is clear. But INCREASE and DECREASE trouble me. A cpufreq governor
needs to be generic, e.g. it needs to work on many different CPUs in many
different surroundings. You can't really tell whether there are two, four or
even thousands of possible "frequency steps". So relying on "frequency
steps" is fundamentally broken in cpufreq governors / CPU frequency 
scaling algorithms -- you need to say "increase one step, but _at least_ 5%
of the CPU maximum frequency!"

		float util;

		/* Calculate utilization. Get a real between 0 and 1.
		 * I need the float cast because result will be 0.xxxxxxx,
		 * which would otherwise get truncated to 0 before being
		 * assigned to util.
		 */
		util = (float) run_jiffies /
			p->task_load_array[i].orig_time_slice;

You can't do that -- the kernel doesn't support floating point math (it's in
the Linux-kernel FAQ somewhere if you need details). As the next code line is

		util_int = util * p->task_load_array[i].speed;

you can simplify it to

		util_int = (p->task_load_array[i].speed * run_jiffies)
		util_int /= p->tark_load_array[i].orig_time_slice


4.) future

It'd be great if you could provide (several) independent "diffs", which can
then be discussed in detail on this list or elsewhere (e.g. linux-kernel for the
details on the scheduler).

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: Dynamic frequency governor

[Dave Jones]

On Fri, Oct 17, 2003 at 02:14:38PM -0700, Moore, Robert wrote:
 
 > I've been chartered to implement a multi-state algorithm for Linux;
 > this will be a new governor that adjusts the CPU frequency based upon
 > percent CPU utilization as reported from the kernel idle handler.
 > 
 > Has any work been done (or is being done) in this area?  I don't want to
 > rewrite the wheel.

There are several patents in this area (I think from Hitachi, I forget
exactly) It has come up before on the list, so should be in the
archives.  Unless you can get a grant from the holder that it may be
used in GPL code, this has zero chance of being merged to mainline.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Daniel Thor Kristjansson]

I made a list here:
  http://www.mrl.nyu.edu/~danielk/linux/cpufreq.html

I just added Jeroen van der Vegt's slowmotion.

I'm going to second everyone else that's written one of these and say
that it should be in userspace. Before I got to busy, my plan was to
make a server that ran an interpreted policy from a file. An applet
running under either kde or gnome would tell it which one to use via a
unix socket. I can post the latest version I wrote, but it's not
thread safe and not secure against buffer overflows (which is why I kept
it to myself).

BTW If you require KDE it already has a system information server that
will tell you if you are running on battery, and more detailed CPU
utilization info than uptime will give you. I also allowed setting CPU
speed based on temperature in addition to battery capacity and uptime,
sometimes I leave a laptop in my lap where I'm sensitive to a 80 deg
Centigrade CPU.... So sometimes, for 65C CPU, I can bear a sligtly
longer compile even if slowing the CPU uses more battery for the
process, especially if I'm plugged in anyway.

-- Daniel
  << When truth is outlawed; only outlaws will tell the truth. >> - RLiegh

On Fri, 17 Oct 2003, Moore, Robert wrote:

]Hi all,
]
]I've been chartered to implement a multi-state algorithm for Linux;
]this will be a new governor that adjusts the CPU frequency based upon
]percent CPU utilization as reported from the kernel idle handler.
]
]Has any work been done (or is being done) in this area?  I don't want to
]rewrite the wheel.
]
]Thanks,
]Bob Moore
]Intel Corporation
]
]_______________________________________________
]Cpufreq mailing list
]Cpufreq@www.linux.org.uk
]http://www.linux.org.uk/mailman/listinfo/cpufreq
]

RE: Dynamic frequency governor

[Moore, Robert]

I'm planning on integrating the previously released Linux IST (Intel
Speedstep) driver into the CpuFreq architecture.

I think that what is gained by having this code in the kernel is that a
very accurate measure of percent CPU utilization can be obtained
directly from the kernel idle handler, and there is less overhead during
the periodic sampling of the current CPU utilization by a timer thread.

Bob


-----Original Message-----
From: Dave Jones [mailto:davej@redhat.com] 
Sent: Sunday, October 19, 2003 6:24 AM
To: Moore, Robert
Cc: cpufreq@www.linux.org.uk
Subject: Re: Dynamic frequency governor

On Fri, Oct 17, 2003 at 02:14:38PM -0700, Moore, Robert wrote:
 
 > I've been chartered to implement a multi-state algorithm for Linux;
 > this will be a new governor that adjusts the CPU frequency based upon
 > percent CPU utilization as reported from the kernel idle handler.
 > 
 > Has any work been done (or is being done) in this area?  I don't want
to
 > rewrite the wheel.

There are several patents in this area (I think from Hitachi, I forget
exactly) It has come up before on the list, so should be in the
archives.  Unless you can get a grant from the holder that it may be
used in GPL code, this has zero chance of being merged to mainline.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Dave Jones]

On Mon, Oct 20, 2003 at 08:31:08AM -0700, Moore, Robert wrote:
 > 
 > I'm planning on integrating the previously released Linux IST (Intel
 > Speedstep) driver into the CpuFreq architecture.

Cool, but what does it do that the existing cpufreq speedstep drivers don't ?

 > I think that what is gained by having this code in the kernel is that a
 > very accurate measure of percent CPU utilization can be obtained
 > directly from the kernel idle handler, and there is less overhead during
 > the periodic sampling of the current CPU utilization by a timer thread.

I'm not disputing whether or not putting this in the kernel is a good
or bad thing (for the record, I think it's a good idea), however the
fact remains, whilst there are folks owning patents on this, it'll
*never* be acceptable for merging without an exception grant from the
patent holder.

		Dave


 > From: Dave Jones [mailto:davej@redhat.com] 
 > Sent: Sunday, October 19, 2003 6:24 AM
 > To: Moore, Robert
 > Cc: cpufreq@www.linux.org.uk
 > Subject: Re: Dynamic frequency governor
 > 
 > On Fri, Oct 17, 2003 at 02:14:38PM -0700, Moore, Robert wrote:
 >  
 >  > I've been chartered to implement a multi-state algorithm for Linux;
 >  > this will be a new governor that adjusts the CPU frequency based upon
 >  > percent CPU utilization as reported from the kernel idle handler.
 >  > 
 >  > Has any work been done (or is being done) in this area?  I don't want
 > to
 >  > rewrite the wheel.
 > 
 > There are several patents in this area (I think from Hitachi, I forget
 > exactly) It has come up before on the list, so should be in the
 > archives.  Unless you can get a grant from the holder that it may be
 > used in GPL code, this has zero chance of being merged to mainline.
 > 
 > 		Dave
 > 
 > -- 
 >  Dave Jones     http://www.codemonkey.org.uk
---end quoted text---

-- 
 Dave Jones     http://www.codemonkey.org.uk

RE: Dynamic frequency governor

[Moore, Robert]

It would be in the kernel as a new governor in the CpuFreq architecture.
From what I can tell, this has not been done yet; is this true?

Bob


-----Original Message-----
From: Dave Jones [mailto:davej@redhat.com] 
Sent: Monday, October 20, 2003 8:40 AM
To: Moore, Robert
Cc: cpufreq@www.linux.org.uk; Walz, Michael
Subject: Re: Dynamic frequency governor

On Mon, Oct 20, 2003 at 08:31:08AM -0700, Moore, Robert wrote:
 > 
 > I'm planning on integrating the previously released Linux IST (Intel
 > Speedstep) driver into the CpuFreq architecture.

Cool, but what does it do that the existing cpufreq speedstep drivers
don't ?

 > I think that what is gained by having this code in the kernel is that
a
 > very accurate measure of percent CPU utilization can be obtained
 > directly from the kernel idle handler, and there is less overhead
during
 > the periodic sampling of the current CPU utilization by a timer
thread.

I'm not disputing whether or not putting this in the kernel is a good
or bad thing (for the record, I think it's a good idea), however the
fact remains, whilst there are folks owning patents on this, it'll
*never* be acceptable for merging without an exception grant from the
patent holder.

		Dave


 > From: Dave Jones [mailto:davej@redhat.com] 
 > Sent: Sunday, October 19, 2003 6:24 AM
 > To: Moore, Robert
 > Cc: cpufreq@www.linux.org.uk
 > Subject: Re: Dynamic frequency governor
 > 
 > On Fri, Oct 17, 2003 at 02:14:38PM -0700, Moore, Robert wrote:
 >  
 >  > I've been chartered to implement a multi-state algorithm for
Linux;
 >  > this will be a new governor that adjusts the CPU frequency based
upon
 >  > percent CPU utilization as reported from the kernel idle handler.
 >  > 
 >  > Has any work been done (or is being done) in this area?  I don't
want
 > to
 >  > rewrite the wheel.
 > 
 > There are several patents in this area (I think from Hitachi, I
forget
 > exactly) It has come up before on the list, so should be in the
 > archives.  Unless you can get a grant from the holder that it may be
 > used in GPL code, this has zero chance of being merged to mainline.
 > 
 > 		Dave
 > 
 > -- 
 >  Dave Jones     http://www.codemonkey.org.uk
---end quoted text---

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Dave Jones]

On Mon, Oct 20, 2003 at 09:33:04AM -0700, Moore, Robert wrote:

 > >From what I can tell, this has not been done yet; is this true?

Correct. For the reason I outlined...

 > however the fact remains, whilst there are folks owning patents on
 > this, it'll *never* be acceptable for merging without an exception
 > grant from the patent holder.

Here, and...

 > > There are several patents in this area (I think from Hitachi, I forget
 > > exactly) It has come up before on the list, so should be in the
 > > archives.  Unless you can get a grant from the holder that it may be
 > > used in GPL code, this has zero chance of being merged to mainline.

Here.
Do I need to quote it a third time ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Daniel Thor Kristjansson]

What are these patents?

There may be a way to write some byzantine logic that avoids touching
them. Canon managed to make photocopiers that avoided touching HP's
patents by splitting up some of the components in strange and illogical
ways. Maybe we can find a gaggle of patent lawyers that will do some
pro-bono work of interpreting these patents into English.

-- Daniel
  << When truth is outlawed; only outlaws will tell the truth. >> - RLiegh

On Mon, 20 Oct 2003, Dave Jones wrote:

]On Mon, Oct 20, 2003 at 09:33:04AM -0700, Moore, Robert wrote:
]
] > >From what I can tell, this has not been done yet; is this true?
]
]Correct. For the reason I outlined...
]
] > however the fact remains, whilst there are folks owning patents on
] > this, it'll *never* be acceptable for merging without an exception
] > grant from the patent holder.
]
]Here, and...
]
] > > There are several patents in this area (I think from Hitachi, I forget
] > > exactly) It has come up before on the list, so should be in the
] > > archives.  Unless you can get a grant from the holder that it may be
] > > used in GPL code, this has zero chance of being merged to mainline.
]
]Here.
]Do I need to quote it a third time ?
]
]		Dave
]
]

Re: Dynamic frequency governor

[Ducrot Bruno]

On Mon, Oct 20, 2003 at 06:00:10PM +0100, Dave Jones wrote:
> On Mon, Oct 20, 2003 at 09:33:04AM -0700, Moore, Robert wrote:
> 
>  > >From what I can tell, this has not been done yet; is this true?
> 
> Correct. For the reason I outlined...
> 
>  > however the fact remains, whilst there are folks owning patents on
>  > this, it'll *never* be acceptable for merging without an exception
>  > grant from the patent holder.
> 
> Here, and...
> 
>  > > There are several patents in this area (I think from Hitachi, I forget
>  > > exactly) It has come up before on the list, so should be in the
>  > > archives.  Unless you can get a grant from the holder that it may be
>  > > used in GPL code, this has zero chance of being merged to mainline.
> 
> Here.
> Do I need to quote it a third time ?
> 
> 		Dave
> 

AFAIR, there is no patent if wide system policy which is what Bob want
to implement.  Only per-process (which is the most fun unfortunately) are
patented.  That need to be confirmed though (by Alan ?).

-- 
Ducrot Bruno

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

Re: Dynamic frequency governor

[Dave Jones]

On Mon, Oct 20, 2003 at 07:25:03PM +0200, Ducrot Bruno wrote:

 > AFAIR, there is no patent if wide system policy which is what Bob want
 > to implement.  Only per-process (which is the most fun unfortunately) are
 > patented.  That need to be confirmed though (by Alan ?).

I was under the understanding that there was a patent on
"recalculate cpu frequency based on idle time" too.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Ducrot Bruno]

On Mon, Oct 20, 2003 at 06:32:05PM +0100, Dave Jones wrote:
> On Mon, Oct 20, 2003 at 07:25:03PM +0200, Ducrot Bruno wrote:
> 
>  > AFAIR, there is no patent if wide system policy which is what Bob want
>  > to implement.  Only per-process (which is the most fun unfortunately) are
>  > patented.  That need to be confirmed though (by Alan ?).
> 
> I was under the understanding that there was a patent on
> "recalculate cpu frequency based on idle time" too.
> 

Grumble.  I was probably mistaken.  Sorry.

-- 
Ducrot Bruno

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

Re: Dynamic frequency governor

[Dave Jones]

On Mon, Oct 20, 2003 at 07:35:09PM +0200, Ducrot Bruno wrote:
 > >  > AFAIR, there is no patent if wide system policy which is what Bob want
 > >  > to implement.  Only per-process (which is the most fun unfortunately) are
 > >  > patented.  That need to be confirmed though (by Alan ?).
 > > I was under the understanding that there was a patent on
 > > "recalculate cpu frequency based on idle time" too.
 > Grumble.  I was probably mistaken.  Sorry.
 
It's not outside the realms of possibility that it's me that was
mistaken. I've been wrong before, and no doubt will be again at some
point 8-)   I'd like to be proven wrong on this one 8-)

		Dave


-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Sven Dowideit]

Hey guys,

can we avoid the issue completely, by taking something like powertweak,
which will let you monitor any system value(s), and then use a
combination of the values the user selected to determine the speed? 

(though on my BX notebook i only get 2 speed, 700Mhz and 850Mhz)

though most of this functionality does not exist in powertweak yet.. I
still need to add getting values at regular intervals, and some generic
calculation engine.

the first i will do anyway as i want to provide a graph


sven

On Tue, 2003-10-21 at 03:35, Ducrot Bruno wrote:
> On Mon, Oct 20, 2003 at 06:32:05PM +0100, Dave Jones wrote:
> > On Mon, Oct 20, 2003 at 07:25:03PM +0200, Ducrot Bruno wrote:
> > 
> >  > AFAIR, there is no patent if wide system policy which is what Bob want
> >  > to implement.  Only per-process (which is the most fun unfortunately) are
> >  > patented.  That need to be confirmed though (by Alan ?).
> > 
> > I was under the understanding that there was a patent on
> > "recalculate cpu frequency based on idle time" too.
> > 
> 
> Grumble.  I was probably mistaken.  Sorry.

RE: Dynamic frequency governor

[Moore, Robert]

Can you be more specific about who has patents on what?
Bob


-----Original Message-----
From: Dave Jones [mailto:davej@redhat.com] 
Sent: Monday, October 20, 2003 10:00 AM
To: Moore, Robert
Cc: cpufreq@www.linux.org.uk
Subject: Re: Dynamic frequency governor

On Mon, Oct 20, 2003 at 09:33:04AM -0700, Moore, Robert wrote:

 > >From what I can tell, this has not been done yet; is this true?

Correct. For the reason I outlined...

 > however the fact remains, whilst there are folks owning patents on
 > this, it'll *never* be acceptable for merging without an exception
 > grant from the patent holder.

Here, and...

 > > There are several patents in this area (I think from Hitachi, I
forget
 > > exactly) It has come up before on the list, so should be in the
 > > archives.  Unless you can get a grant from the holder that it may
be
 > > used in GPL code, this has zero chance of being merged to mainline.

Here.
Do I need to quote it a third time ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[Dave Jones]

On Mon, Oct 20, 2003 at 10:08:17AM -0700, Moore, Robert wrote:
 > Can you be more specific about who has patents on what?

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,298,448.WKU.&OS=PN/6,298,448&RS=PN/6,298,448
Is a good place to start.  Skimming through the references there brings
up further patents by just about everyone under the sun, including
Intel.

It looks a little murky in my not-professional-legal-person POV.
If Intel are looking at funding this work, it would be fantastic
to have their legal folks clear things up to be sure that this is
safe ground.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: Dynamic frequency governor

[David Kar-Fai Tam]

On Tue, 21 Oct 2003, Dave Jones wrote:
> On Mon, Oct 20, 2003 at 10:08:17AM -0700, Moore, Robert wrote:
>  > Can you be more specific about who has patents on what?
> 
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,298,448.WKU.&OS=PN/6,298,448&RS=PN/6,298,448
> Is a good place to start.  Skimming through the references there brings
> up further patents by just about everyone under the sun, including
> Intel.

Here's an idea:

I did a quick text search on the website of the above address and I 
couldn't find "voltage" mentioned anywhere. That is, I couldn't find any 
mention of dynamic "voltage" scaling as a technique for saving power.
They only talk about is using the technique of "frequency" scaling to 
save power.

With DVS algorithms, we are attempting to dynamically change the voltage 
to save power. The fact that the frequency varies is just a side effect.

How's that for finding a loop hole? =)

I don't want to get into a long discussion about whether frequency scaling
alone can save you energy. I think that we are ultimately trying to vary
the voltage because only that can really save you energy (quadratically). 
Maybe we should have named it the CPUVolt API?

--
David Tam
tamda@eecg.toronto.edu

Re: Dynamic frequency governor

[Dave Jones]

On Tue, Oct 21, 2003 at 06:21:37PM -0400, David Kar-Fai Tam wrote:

 > I did a quick text search on the website of the above address and I 
 > couldn't find "voltage" mentioned anywhere. That is, I couldn't find any 
 > mention of dynamic "voltage" scaling as a technique for saving power.
 > They only talk about is using the technique of "frequency" scaling to 
 > save power.
 > 
 > With DVS algorithms, we are attempting to dynamically change the voltage 
 > to save power. The fact that the frequency varies is just a side effect.

Not all implementations can scale voltage.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk